ADA104882 


Submitted  to: 


Battelle  Columbus  Laboratories 
Durham  Operations 
3333  Chapel  Hill  Boulevard 
P.0.  Box  8796 
Durham,  NC  27707 


Contracting  Officer's  Technical  Representative: 


Mr.  James  Gantt 
AIRMICS 

Georgia  Institute  of  Technology 
Atlanta,  GA  30332 


"Brief  Survey  of  Operational 
DECISION  SUPPORT  SYSTEMS" 


Final  Report  -  Contract  DAAG29-76-D-0100 
Delivery  Order  No.  1002 

1  February  1979 


Prepared  by: 

Leslie  G.  Callahan,  Jr. 

School  of  Industrial  and  Systems  Engineering 
Georgia  Institute  of  Technology 
Atlanta,  GA  30332 


Findings  and  opinions  expressed  herein  are  those  of  the  author  and 
should  not  be  construed  as  official  Department  of  the  Army  positions, 
policies,  or  decisions,  unless  so  designated  by  other  documentation. 


Security  Classification: 


UNCLASSIFIED 


* 


EXECUTIVE  SUMMARY 


The  purpose  of  this  project  was  to  conduct  a  brief  survey  and 
analysis  of  three  operational  Decision  Support  Systems  (DSS)  in  the 
private  sector  and  one  experimental  system  which  lead  to  15  applica¬ 
tions  in  the  public  sector.  The  three  public  sector  DSS  were  RCA  IRIS, 
Gould  Corp.  WINS,  and  First  Chicago  EIS .  The  experimental  system  was 
the  IBM  GADS,  and  specific  attention  is  directed  at  the  San  Jose  - 
Police  Beat  application.  A  literature  survey  was  conducted  in  order 
to  develop  a  methodological  framework  for  the  survey.  The  methodology 
selected  was  to  examine  each  system  in  terms  of  1)  the  operational 
environment  in  which  the  system  was  developed,  2)  the  major  events, 
individuals  and  actions  that  influenced  system  design  and  implementa¬ 
tion,  3)  system  architectures  (User-Software-Hardware),  and  4)  major 
operational  characteristics  (i.e..  Internal  Security,  Training,  Main¬ 
tenance  and  Support) . 

It  was  concluded  that  a  number  of  similarities  were  exhibited  in 
all  of  the  four  systems  examined:  1)  three  to  four  years  were  required 
for  development  and  implementation,  2)  each  system  had  the  strong  sup¬ 
port  of  the  senior  management  or  Chief  Executive  Officer  when  develop¬ 
ment  was  initiated,  3)  all  systems  had  a  "broker"  who  coalesced  user, 
technical  and  management  interests  for  common  support  for  development 
and  implementation,  and  4)  all  systems  had  a  capability  for  evolution 
or  "architectural  adaptability."  It  was  also  concluded  that  DSS  devel¬ 
opment  in  the  public  sector  is  much  more  difficult  than  the  private 
sector  because  of  the  need  in  the  public  sector  for  contract  specifi¬ 
cations  and  performance  standards  which  currently  are  virtually  non¬ 
existent.  Internal  security  is  of  great  importance  in  the  private 
j,  sector  for  multi-level  users  of  DSS  with  widely  dispersed  terminals, 

t  _  but  was  of  little  concern  for  public  systems.  Of  the  four  systems, 

{  '  the  RCA  IRIS  represents  the  best  overall  example  of  an  operational  DSS 

*  which  has  become  institutionalized  in  an  organizational  setting,  is 

capable  of  architectural  adaptation,  is  used  by  both  corporate  staff 
and  operational  unit  managers  for  both  strategic  and  tactical  decision 
making  in  the  field  of  personnel  management,  has  an  effective  internal 
security  system,  a  good  training  program,  has  an  effective  on-line 
operational  cost/effectiveness  evaluation  system,  and  satisfies  the 
dual  perceptions  of  the  senior  corporate  executives  as  well  as  the 
field  units  without  disturbing  organizational  integrity. 

Based  on  the  survey  it  is  recommended  that  AIRMICS  take  immediate 
action  to  organize  a  DSS  workshop  with  representation  from  successful 
operational  systems  who  would  conduct  hands-on  demonstrations  and  present 
case  studies,  vendors  to  present  the  state  of  DSS  software  and  hardware 
technology,  academicians  who  represent  the  major  disciplines  involved  in 
DSS  R  and  D,  and  potential  Army  users  who  have  potential  areas  of  appli¬ 
cation.  It  is  also  recommended  that  a  research  effort  be  initiated  to  ~  '• 
examine  the  current  state  of  DSS  evaluation  methodologies  and  their  com-  } 
patibility  with  DOD  policies  and  to  recommend  alternative  solutions. 
Finally  it  is  recommended  that  after  a  review  and  critique  of  this 
report  is  completed,  that  a  second  iteration  be  initiated  with  a  refined 
set  of  factors  and  attributes.  The  second  iteration  would  be  directed 
at  an  investigation  of  a  more  selective  target  set  and  a  bigger  sample 
of  operational  systems  which  could  provide  a  more  definitive  baseline 
to  guide  the  Army  in  applying  DSS  technologies  to  Army  computer  systems. 
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1.  INTRODUCTION 


1 . 1  Purpose 

The  Management  Information  Science  Division  of  AIRMICS  has  begun  a 
research  program  to  investigate  the  potential  application  of  Decision 
Support  System  (DSS)  technologies  to  improve  the  operations  of  business  „ 
type  electronic  data  processing  (EDP)  systems  used  by  the  Army.  As 
part  of  this  program,  it  was  decided  that  a  baseline  survey  and  analysis 
should  be  made  of  a  cross  section  of  DSS  currently  in  use  within  the 
civilian  community.  As  given  in  the  Statement  of  Work  for  this  survey 
(Appendix  A)  the  objective  is  "to  produce  an  analysis  of  existent  DSS  and 
their  supporting  hardware  and  software  technology  base,  and  to  recommend 
further  research  into  potential  applications  of  this  technology  to  computer 
systems."  Specific  tasks  include  "gather  and  analyze  published  work  on 
DSS  developed  for  use  in  the  civilian  community",  and  "review  and  analyze 
reasons  for  success  or  failure  of  DSS  developed  for  civilian  use."  As  a 
minimum  a  detailed  investigation  was  required  of  the  IBM  Geodata  Analysis 
and  Display  System  (GADS),  the  First  National  Bank  (Chicago)  Executive  In¬ 
formation  System  (EIS) ,  the  Gould  Corp  Worldwide  Information  System  (WINS), 
and  the  RCA  Industrial  Relations  Information  System  (IRIS). 

1 . 2  Methods  and  Scope 

Work  under  this  study  was  restricted  to  twenty  man  days  of  effort 
during  the  period  30  August  1978  to  15  January  1979.  One  half  of  the  effort 
was  devoted  to  informal  staff  discussions,  literature  review,  and  report  wri¬ 
ting  in  the  Atlanta  area,  and  approximately  ten  days  were  spent  on  field 
trips  to  IBM  -  San  Jose,  California,  First  National  Bank  and  Gould  Corp., 
Chicago,  Illinois,  and  to  the  RCA  Corporate  Operations  Research  Staff  at 
Princeton,  New  Jersey. 

1. 3  Organization  of  Report 

Chapter  2  gives  a  summary  of  the  literature  review  including  an  aggre¬ 
gated  list  of  DSS  descriptive  attributes  and  operations.  Chapter  3  discusses 
the  survey  methodology  which  is  centered  around  the  investigation  of  the 
life  cycle  evolution  of  the  four  specified  experimental  or  operational  DSS 
in  terms  of  their  operational  environments,  major  events,  architecture,  and 
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operational  characteristics.  Chapters  4  through  7  are  dedicated  to  a 
discussion  of  each  system  individually,  but  from  the  same  methodological 
overview.  Finally,  Chapter  8  presents  a  synthesis  of  overall  conclusions 
and  a  set  of  recommendations  for  future  Army  research.  The  bulk  of  the 
material  collected  for  this  project,  such  as  user  manuals,  corporation 
reports  and  examples  have  not  been  made  part  of  this  report,  but  will 
be  made  available  to  A1RMICS  as  the  need  arises. 

2 .  LITERATURE  REVIEW  AND  DEFINITIONS 
2. 1  DSS  Concepts  and  Taxonomies 

Since  the  early  1970Ts  the  term  "decision  support  system1'  (DSS)  has 
been  increasingly  used  in  management  science,  operation  research  and  com— 
puter  system  publications  to  denote  an  interactive,  computer  based  system 
which  is  designed  to  aid  executive  level  professionals  in  solving  ad  hoc, 
unstructured  problems  without  acquiring  a  knowledge  of  programming  tech¬ 
niques.  Typically,  these  systems  are  distinguished  from  the  more  tradi¬ 
tional  EDP  applications,  which  are  said  to  be  designed  to  automate  clerical 
tasks  and  to  promote  efficient  record  keeping.  Although  a  certain  amount 
of  conjecture  has  been  generated  concerning  the  "nature"  of  decision  support 
systems,  the  importance  of  interactive  problem  solving,  the  relevance  of 
certain  system  characteristics,  the  need  for  special  implementation  skills 
and  design  processes,  and  so  on,  there  is  little  empirical  data  and  the 
conjectures  are  often  contradictory.  In  addition,  there  is  little  agree¬ 
ment  concerning  general  scope,  definitions  of  terms,  identification  of  vari¬ 
ables,  and  other  prerequisites  for  the  coalescence  of  an  organized  disci¬ 
pline  in  which  research  can  take  place  using  standard  research  methodologies 
As  number  of  investigators  here  attempted  to  develop  taxonomies  of  DSS 
according  to  usage  patterns.  In  1975  Alter  categorized  56  developmental 
and  operational  systems  into  seven  distinct  types  which  he  labeled  as 
follows  (1) : 

(1)  File  drawer  systems  which  allow  immediate  access  to  data 
items. 

(2)  Data  analysis  systems  which  allow  the  manipulation  of  data 
by  means  of  operators  tailored  to  the  task  and  setting  or 
operators  of  a  general  nature. 

(3)  Analysis  information  systems  which  provide  access  to  a  series 
of  data  bases  and  small  models. 


(4)  Accounting  models  that  calculate  the  consequences  of  planned 
actions  based  accounting  definitions. 

(5)  Representational  models  that  estimate  the  consequences  of 
actions  based  on  models  which  are  partially  non-def initional . 

(6)  Optimization  models  that  provide  guidelines  for  action  by 
generating  the  optimal  solutions  consistent  with  a  series  of 
cons  traints . 

(7)  Suggestion  models  that  perform  mechanical  work  leading  to  a 
specific  suggested  decision  for  a  fairly  structured  task. 

Figure  1  illustrates  how  Alter  collapsed  this  taxonomy  into  a  dich¬ 
otomy  between  data-oriented  and  model-oriented.  Data-oriented  systems  are 
usually  developed  by  persons  with  data  processing  or  computer  science 
backgrounds,  whereas  model-oriented  systems  are  developed  by  persons  with 
management  science  backgrounds,  such  as  accounting,  simulation,  or  opti¬ 
mization. 

File  Drawer  Systems 
Data  Analysis  Systems 


Data  Retrieval 


Data-Oriented 


Data  Analysis 


Analysis  Information  Systems 


Accounting  Models 
Representational  Models 


Simulation 


Optimization  Models 
Suggestion  Models 


Suggestion 


Model-Oriented 


Data-Oriented  vs.  Model— Oriented  Decision  Support  System  Tynes 

Figure  1 

Keen  and  Morton  (2)  have  attempted  to  define  DSS  in  terms  of  un¬ 
structured,  semi-structured  and  structured  decision  making  at  various  levels 
of  management  activity  ranging  from  operational  control,  management  control 
to  strategic  planning.  Donovan  and  Madnick  extended  this  notion  to  ad  hoc 
and  institutional  (3) .  Institutional  DSS  deals  with  decisions  of  recurring 
nature  where  the  problem  definition  remains  relatively  stable  once  it  is 
understood,  though  the  decision  algorithm  may  be  unstructured.  An  ad  hoc 
DSS  is  concerned  with  aiding  decision  making  for  a  wide  variety  of  problems 
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that  tare  not  usually  anticipated  or  recurring.  The  specific  problems 
are  usually  poorly  defined ,  the  decision  is  needed  very  soon,  and  the  de¬ 
cision  maker's  perception  of  the  problem  and  even  the  inherent  nature  of 
the  problem  may  change  during  the  process.  An  ad  hoc  DSS  must  focus  on 
responding  quickly  with  needed  information  and  analysis  on  a  one-time  basis 
for  a  specific  decision.  A  graphical  composite  of  Keen,  Morton,  Donovan, 
and  Madnick's  taxonomy  is  shown  in  Figure  2. 

2 . 2  The  Multi-Disciplinary  Nature  of  DSS  Evolution 

A  principle  reason  for  the  lack  of  a  coalescence  of  DSS  definition 
and  concept  is  due  to  the  multi-disciplinary  nature  of  their  envolutionary 
development  X'/hich  transcends  conventional  disip  lines  in  computer  science, 
management  science,  ergonomics  (human  factors),  operations  research  and 
behavorial  science.  Edelman  considers  that  the  development  of  interactive, 
time-shared  computing,  and  data  base  management  with  high  level  inquiry 
languages  proved  to  be  the  two  major  breakthroughs  in  the  past  decade  which 
permitted  development  of  the  RCA  Industrial  Relations  Information  Systems 
(IRIS)  (4).  Keen  and  Morton  emphasize  the  confluence  of  Simon's  work  on 
the  dynamics  of  organizational  decision  making  at  Carnegie  and  MIT's  work 
on  interactive  time-sharing  computation  which  began  with  project  MAC  (2). 
Other  investigations  such  as  A.  H.  Schmidt  of  Harvard's  Laboratory  for  Com¬ 
puter  Graphic  and  Spatial  Analysis  and  E.  Carlson  of  IBM's  San  Jose  Research 
Laboratory  have  emphasized  the  application  of  computerized  cartography  and 
computer  aided  design  technolgies.  L.  M.  Branscomb,  Chief  Scientist  of  IBM, 
recently  emphasized  the  need  for  more  research  in  the  human  factors  area  to 
improve  human-computer  communications  (5)  . 

One  of  the  earliest  attempts  at  bridging  the  multi-disciplinary  gap 
was  made  at  a  January  1977  conference  on  Decision  Support  Systems  at  Santa 
Clara,  California.  The  Conference  was  jointly  sponsored  by  the  Association 
of  Computing  Machinery,  IBM  Research  Division,  Sloan  School  MIT,  and  the 
Wharton  School.  The  proceedings  were  published  in  a  ACM  publication  Data 
Base ,  Winter  1977  and  were  edited  by  E.  D.  Carlson  (6).  Papers  reported 
both  experimental  and  operational  results,  and  included  discussions  of 
eight  systems  such  as  General  Motors  Relational  General  Information  Sytem 
(REGIS),  RCA's  Industrial  Relations  Information  System  (IRIS),  First  Na¬ 
tional  Bank  Chicago's  Executive  Information  System  (EIS).  Other  papers 
discussed  research  related  to  the  design  of  display  systems  and  to  attempts 
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at  improving  training  programs  for  users.  The  conference  was  attended  by 
; i bon L  160  individuals  v/ith  about  half  from  private  industry,  and  represent¬ 
ing  all  of  the  disciplines  cited  above.  The  flyer  for  the  Santa  Clara 
conference  gave  another  perception  of  the  distinction  between  DSS  and 
traditional  computer-based  approaches  to  problem  solving: 

’’Decision  Support  Systems  are  different  from  traditional 
computer-based  approaches  to  problem  solving  in  that  they 
are  used  to  help  solve  the  unstructured  problems  typical 
of  the  decision  maker *s  real  world.  Unlike  the  traditional 
techniques  of  operations  research  and  computer  simulation. 

Decision  Suoport  Systems  rely  on  the  decision  maker Ts  in¬ 
sights  and  judgement  at  all  stages  of  problem  solving  - 
from  problem  formulation,  to  choosing  the  relevant  data 
to  work  with,  to  picking  the  approach  to  be  used  in  gen¬ 
erating  solutions,  and  on  to  evaluating  the  solutions 
presented  to  the  decision  maker.11 

Figures  3  and  4  respectively,  reflect  pictorial  concepts  of  computer  aided 
decision  making  and  a  user-DSS  system  configuration  with  an  intermediary. 

2 • 3  Summary  of  DSS-User  Operations  and  Attributes 

In  spite  of  the  lack  of  a  common  taxonomy  or  coalescence  of  DSS  de¬ 
finitions  and  con-epts,  there  is  a  general  consensus  as  to  the  operations 
that  a  joint  user  -  DSS  system,  (man-software-hardware),  should  be  cap¬ 
able  of  performing.  Alter  summarized  these  operations  as  (7): 

(1)  Retrieve  isolated  data  items. 

(2)  Use  a  mechanism  for  ad  hoc  analysis  of  data  files. 

(3)  Obtain  prespecified  aggregations  of  data  in  the  form  of 
standard  reports. 

(4)  Estimate  the  consequences  of  proposed  decisions. 

(5)  Propose  decisions. 

(6)  Make  decisions. 

Alter  noted  that  the  difference  between  classical  EDP  system  and  a  DSS  is 
that  the  EDP  -  user  system  can  only  perform  the  third  operation  listed 
above . 

In  summary,  a  review  of  the  current  literature  on  DSS  results  in  the 
following  aggregation  of  descriptive  attributes: 
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Figure  4 

Decision  Support  System 


(1) 


System  characteristics: 


(a)  A  DSS  SUPPORTS,  not  replaces,  the  decision  maker. 
(Indeed  the  DSS-User  combination  may  be  viewed  as 

a  system) 

(b)  A  DSS  is  USER-ORIENTED;  thus,  the  user  should 
play  a  key  role  in  the  design  and  implementation* 

(2)  Decision  making  characteristics: 

(a)  A  DSS  can  effectively  support  both  STRATEGIC  PLAN¬ 
NING,  and  Tactical  Operations. 

(b)  A  DSS  can  effectively  support  SEMI-STRUCTURED 
decisions,  in  addition  to  Structured  decisions. 

(c)  A  DSS  can  effectively  support  AD  HOC  decisions, 
in  addition  to  Institutional  decisions. 

(3)  Users : 

(a)  A  DSS  is  ADAPTIVE  to  more  than  one  decision  maker 
or  decision  making  style. 

(b)  A  decision  maker (s)  may  use  an  INTERMEDIARY 
(chauffer)  to  interface  with  the  DSS. 

(4)  Software: 

(a)  The  DSS  is  an  INTERACTIVE  (not  conversational) 
time-sharing  system  with  user-level  command 
language  and  vocabulary. 

(b)  The  DSS  interfaces  with  an  EXTRACTED  DATA  BASE,  a 
subset  of  a  large  data  base  management  system. 

(c)  The  software  contains  a  library  of  prewritten 
MODELS. 

(d)  The  software  is  FLEXIBLE  for  developing  new  models 
for  ad  hoc,  Mwhat  if"  simulations. 

(5)  Hardware : 

(a)  The  decision  maker (s)  or  intermediary  interact 
through  a  terminal  device,  most  mentionably  a 
VISUAL-DISPLAY  TERMINAL  with  graphics  capabilities 
(Other  audio  and  visual  cues  are  sometimes  desirable) . 

(b)  The  hardware  is  FLEXIBLE  for  allowing  the  decision 
maker  to  control  representatic ns ,  operations,  and 
memory  aids  through  suitable  entry  devices. 
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3 .  SURVEY  METHODOLOGY 


3 . 1  Previous  Survey  Methodologies 

The  literature  is  replete  with  examples  or  case  studies  of  "success¬ 
ful11  experimental  and  operational  DSS .  However,  there  has  been  relatively 
little  documented  analysis  and  discussion  of  those  systems  that  failed 
to  survive  in  a  competitive  business  environment  or  did  not  live  up  to 
the  expectations  of  their  sponsors.  Alter rs  1975  survey  of  DSS,  both  % 
successes  and  failures,  provided  a  rich  source  of  raw-ques tionaire  type 
data  which  reflects  the  opinions  of  individual  users,  technicians  and 
managers  (1).  Further,  a  growing  number  of  authors  such  as  Keen,  Morton 
and  Carlson  have  begun  to  investigate  the  DSS  design  process  itself,  the 
problems  of  implementation,  and  the  problem  of  system  evaluation  (2),  (8), 

(9).  Keen  and  Morton  devote  four  chapters  in  their  1978  book  to  these 
problems,  and  point  out  that  unlike  current  practices  or  in  the  R  &  D  and 
Procurement  of  conventional  products,  the  design,  implementation  and  eval¬ 
uation  of  DSS  are  inseparable  and  evolutionary.  They  attribute  the  com¬ 
plexity  of  the  process  to  the  multi-disciplinary  perspectives  of  the  de¬ 
velopers,  the  users  and  sponsors,  and  discuss  several  implementation  strat¬ 
egies  proposed  by  Kolb-Frohman,  R.  L.  Ackoff  and  C.  Argris.  Keen  and  Morton 
conclude  that  there  is  need  for  an  "implementor"  or  "broker"  who  bridges 
the  gap  between  the  OR/MIS  technicians  and  users,  and  sponsors.  In  another 
paper  Morton  reports  the  results  of  a  three  year  study  involving  two  large 
operational  DSS,  and  raises  two  major  issues  (10).  The  first  is  the  im¬ 
portance  of  matching  the  four  components  of  manager,  organizational  struc¬ 
ture,  DSS  technology  and  the  tasks  which  change  after  the  DSS  is  introduced 
in  the  operational  environment  of  the  real  world.  The  second  Is  the  diffi¬ 
culty  of  measuring  the  impact  of  such  systems.  He  stresses  the  need  for 
the  development  of  new  methodologies  that  allow  the  measurement  of  some  of 
the  variables. 

3 . 2  Selected  Approach  and  Factors 

The  methodology  adopted  for  this  study  is  more  structured  than  the 
taxonomy— in terview  approach  used  by  Alter.  However,  it  is  not  as  formal 
as  the  work  of  Keen  and  Morton  which  is  directed  at  the  modeling,  analysis, 
and  quantitive  evaluation  of  the  entire  design-implementation  process  for 
DSS.  Our  approach  is  to  investigate  the  evolution  of  only  four  mature  and 
widely  publicized  DSS  over  their  individual  system  life  cycles.  This  ap- 
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proach  was  adopted  because  the  four  systems  of  interest,  CADS,  WINS,  LIS, 
and  IRIS  each  Restated  in  different  operational  environments  with  different 
types  of  management  sponsorship,  emphasized  different  DSS  technologies  and 
architecture,  and  are  designed  for  different  types  of  users  to  meet  differ¬ 
ent  types  of  operational  requirements.  CADS  was  developed  an  an  experi¬ 
mental  system  to  serve  primarily  as  a  research  tool  for  assisting  non¬ 
program  users  in  the  public  sector  to  solve  unstructured  problems  in  the 
San  Jose  area  related  to  urban  growth,  definition  of  school  district  bound¬ 
aries,  and  design  of  police  beats.  WINS  was  developed  in  a  large  inter¬ 
national  conglomerate  environment  for  use  by  the  CEO  and  other  senior  exe¬ 
cutives.  EIS  was  designed  for  use  in  a  large  bank  by  first  line  loan, 
managers  as  an  add-on  to  an  extensive  data  processing  system.  IRIS  was 
developed  in  a  large  industrial  corporation  as  both  a  MIS  transactional 
system  and  DSS  for  the  solution  of  ad  hoc,  unstructured  problem  solving 
in  the  area  of  personnel  management.  Due  to  the  time  constraints  of  this 
research,  and  the  small  sample  size  of  DSS  surveyed,  no  attempt  will  be 
made  to  formally  rank  order  or  to  determine  the  "best"  system.  Rather, 
our  approach  is  to  investigate  the  similarities  and  difference  of  the  four 
systems  through  an  examination  of  each  system  in  terms  of: 

1.  The  operational  environment  in  which  it  was  developed. 

2.  Major  events,  individuals  and  actions  that  influenced 
system  design  and  implementation. 

3.  System  architecture  (User-Sof tware-Hardwar e) . 

4.  Major  operational  characteristics. 

Based  on  an  examination  of  the  individual  systems,  general  conclusions  and 
recommendations  will  be  made  to  guide  the  Army  in  future  research. 

The  term  "opera tional  environment"  denotes  a  brief  description  of  the 
organizational  and  administrative  setting  in  which  the  DSS  was  developed. 

The  description  is  limited  in  scope  and  content  by  the  terms  of  the  re¬ 
search  effort,  and  is  based  on  interviexv/s  with  a  limited  number  of  personnel 
during  a  short  field  trip,  a  perusal  of  corporate  documentation,  and  the 
author’s  background  and  experience.  An  attempt  will  be  made  to  identify  the 
key  "implementator (s) The  second  area  of  major  events  in  system  develop¬ 
ment  is  based  both  on  interview  and  published  material.  In  the  third  area, 
the  term  system  "architecture"  rarely  appears  in  the  DSS  literature,  although 
it  is  commonly  used  in  the  discussion  of  MIS  and  military  "command  and  con¬ 
trol"  systems.  'for  purposes  of  this  investigation  "architecture"  is  con- 
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sidered  as  the  art  or  science  of  building  systems  for  human  use  through 
the  application  of  engineering  technologies.  Thus,  the  User-DSS  is  viewed 
as  a  system  entity  which  include  the  hardware,  software  and  human  com¬ 
ponents.  The  hardware  includes  general  purpose  time-sharing  computer 
systems,  graphic  terminals,  micro-processors,  keyboard  and  non-keyboard 
entry  devices,  graphics  terminals  and  telecommunication  networks.  The 
software  includes  data-base  management  systems,  operations  research  models 
and  algorithms,  specialized  simulations,  and  graphic  packages.  In  some 
cases  human  component  includes  both  the  user  decision  maker  and,  the 
"chauffeur"  who  acts  as  an  intermediary  such  as  a  technician  or  staff 
officer  as  indicated  in  Figure  4.  The  fourth  area  of  operating  charac¬ 
teristics  denotes  a  number  of  factors  that  can  be  used  to  examine  the 
entire  class  of  operational  DSS.  They  include: 

(1)  internal  security  for  users 

(2)  tactical  operations  or  strategy  planning 
(implies  decision  time  horizon,  level  of 

aggregation  of  data  base,  and  frequency 
of  usage) 

(3)  level  of  individual  user  (implies  use  by 
CEO  or  first  level  managers,  or  joint  usage) 

(4)  individual  decision  making  or  group  consensus 

(5)  use  of  central  data  bank 

(6)  internal  dual  systems  perspective  (implies 
both  corporate  and  operating  units  perceptions 
of  system  utility) 

(7)  Architecture  adaptability 

4 .  INDUSTRIAL  RELATIONS  INFORMATION  SYSTEM  (IRIS) 

4.1  Operational  Environment 

The  RCA  Corporation  is  a  large  industrial  conglomerate  with  1977  sales 
of  6  billion  dollars  and  employees  over  110,000  personnel.  Although  tradi¬ 
tionally  a  national  leader  in  electronics  research  and  development,  and  in 
commercial  broadcasting  and  communications,  RCA  began  to  branch  out  into 
other  industries  in  the  1960's.  It  currently  owns  Coronet  Industries  in 
the  carpet  manufacturing  industry,  the  Hertz  Corporation,  Random  House  and 
Oriel  Foods.  Corporate  offices  are  located  in  New  York  City  with  seven 
major  operating  field  divisions  or  subsidiaries,  each  with  their  own  profit 
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and  loss  responsibilities.  In  the  Industrial  Relations  (human  resources) 
area,  there  are  seventeen  different  personal  management  units  which  main¬ 
tain  complete  compensation  and  performance  records  for  all  employees  in¬ 
cluding  the  corporate  staff.  Many  of  these  units  developed  their  personnel 
policies,  record  management  procedures  and  report  styles  during  the  period 
prior  to  the  time  their  companies  became  part  of  RCA.  Consequently,  there 
was  a  wide  variety  of  responses  in  their  adaptation  to  EDP  technology  in 
the  1960Ts  to  solve  problems  related  to  payrolls,  pension  plans,  adminis¬ 
tration,  insurance,  labor  relationships,  affirmative  action  programs,  and 
many  other  personnel  actions,  including  computerized  in-house  telephone 
directories.  Many  of  EDP  applications  were  not  developed  as  systems,  but 
loose  confederations  of  computer  programs.  Each  such  system  usually 
existed  and  operated  on  a  stand  alone  basis,  with  little  consolidation 
of  reports  or  use  of  common  data  bases. 

4 . 2  Major  Events  in  the  IRIS  Development-Implementation  Cycle 

In  early  1973  the  Corporate  Operations  Research  Group  under  F.  Edleman, 
was  called  in  by  the  Corporate  Vice-president  for  Organization  Development 
and  Compensation  Planning,  to  discuss  the  problem  of  retirement  plan  admin¬ 
istration.  The  EDP  system  existent  at  that  time,  was  not  working  and  in¬ 
capable  of  responding  to  either  changing  governmental  regulatory  demands 
at  the  tactical  operating  level,  or  the  needs  of  corporate  management  for 
strategic  planning.  All  ad-hoc  unstructured  studies  were  accomplished  on 
primarily  manual  basis  by  special  task  forces.  After  investigation  of 
suitable  financial  and  actuarial  models,  and  prelimenary  field  work,  the 
OR  group  in  early  1974  conceptualized,  and  selected  the  architecture  for 
a  DSS  for  use  by  non-computer  oriented  Industrial  Relation  managers  and 
administrators  and  to  serve  both  operating  units  and  corporate  management. 
One  of  the  operating  units  agreed  to  supply  all  its  operational  data  and 
to  serve  as  a  prototype  field  demonstration. 

In  July  1974,  v/ith  corporate  backing,  a  live  system  was  success¬ 
fully  demonstrated  to  all  of  RCA’s  top  Industrial  Relation  executives. 

The  demonstration  included  live  and  ad  hoc  usage  by  the  executives  in 
attendance.  As  a  result  of  the  successful  demonstration,  the  system  was 
named  IRIS  and  the  OR  group  was  commissioned  to  design  and  build  the  entire 
system  and  install  it  in  all  of  RCA’s  major  operating  units.  By  the  end 
of  1974,  the  system,  included  all  custodial  functions,  and  was  suffi- 
cently  complete  to  capture  and  validate  the  operational  data  base  of  a 
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prototype  unit,  and  work  began  to  develop  data  base  maintenance  procedures. 

In  April  1975,  the  pilot  system  began  regular  processing  of  operational  trans¬ 
actions  in  parallel  with  the  then  existent  personnel  data  system.  In 
August  1975,  IRIS  software  was  transferred  from  the  original  laboratory 
environment  at  Princeton  which  used  an  outside  time-sharing  ventor  to 
RCA*  s  internal  computer  facility  at  Cherry  Hill,  New  Jersey.  In  September 
1975,  the  prototype  unit  became  completely  dependent  on  IRIS  and  shut  down 
its  old  system.  By  the  fall  of  1978,  all  but  one  RCA  personnel  department 
relied  on  IRIS.  With  a  6  month  transition  time,  all  divisions  will  be  on 
line  by  the  spring  of  1979. 

4.3  IRIS  Architecture 


4.3.1  General 

IRIS  was  designed  and  developed  for  simultaneous  and  joint  usage  as 
a  transactional  EDP  report  generating  system  and  as  an  ad  hoc  DSS  for 
personnel  managers  and  administrators.  The  entire  system  uses  a  common  data 
base  and  a  commercially  available  data  base  management  system  which  is 
programmed  on  a  centrally  located  and  RCA  operated  IBM  370/168,  located 
at  Cherry  Hill,  hew  Jersey,  under  VM/CMS.  In  addition,  the  IRIS  common 
data  base  is  used  by  a  number  of  other  EDP  systems  for  analysis  and  pro¬ 
cessing,  i.e.,  payroll  operations.  An  extensive  command  language  sector 
has  been  custom  designed  to  stand  between  the  end  user  and  the  data  man¬ 
agement  system.  This  "Executive  Language"  interface  is  largely  respon¬ 
sible  for  providing  the  type  of  human  engineering  needed  to  accommodate 
the  noncomputer-oriented  user.  A  wide  variety  of  user  terminals  are 
supported,  from  teletype  to  high-speed  video  displays.  An  extensive  data 
communications  network  supports  the  system  on  a  national  basis. 

4 . 3.2  User  Language 

The  user  communi cates  with  the  system  through  compact  and  easily 
learned  language  at  three  levels: 

—  The  command  language"  conveys  to  the  system  the  user Ts 
basic  intent  of  what  he  is  trying  to  accomplish:  the 
creation  of  a  new  report  request,  the  changing  of  an 
existing  report  request,  perusal  of  the  library,  logging 
out  and  others.  There  are  altogether  15  basic  commands. 

Each  command  is  a  single  word  which,  when  entered,  will 
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initiate  the  requested  procedures  and  generally  assist 
the  user  if  he  needs  help. 

-  The  "report  request  language”  is  used  to  phrase  a 
particular  report  request.  It  has  a  syntax  which 
is  manageable  by  noncomputer-oriented  individuals 
and  is  easily  learned  after  relatively  short  ex¬ 
posure.  A  formal  course  and  manual  are  made  avail¬ 
able  to  all  system  users  of  the  ad  hoc  sector. 

-  The  "request  editing  language"  is  used  to  change  an 
existing  report  request  and  is  the  simplest  and  most 
compact  of  the  three. 

4.3.3  Data  Management 

Even  though  the  system  has  the  data  base  online  for  inquiry  and  analysis 
purposes  -  an  essential  requirement  for  an  effective  ad  hoc  capability  - 
the  updating  of  each  data  base  takes  place  in  an  off-line  batch  mode.  This 
is  done  for  two  reasons.  First,  it  is  much  cheaper,  and  personnel  data  does 
not  literally  have  to  be  up  to  the  minute.  Once  a  week  updating  is  suffi¬ 
cient  in  most  instances.  Second,  on-line  updating  is  somewhat  more  risky 
from  the  systems  reliability  point  of  view  and,  at  times,  enormously  so. 
Hardware  or  communication  line  malfunctions  during  on-line  updating  can 
cause  problems  from  which  it  is  often  difficult  to  recover.  In  this  in¬ 
stance,  the  designers  ddopted  a  concervative  but  economical  and  time-proven 
approach,  and  to  date  there  has  been  no  indication  whatever  that  a  different 
course  might  have  been  more  advantegeous  for  their  type  of  application. 

4.3.4  Sample  Data  Base  Concept 

To  minimize  cost  of  ad  hoc  usage,  an  inexpensive  means  for  testing 
new  report  request  procedures  is  provided  by  the  system.  The  data  base 
of  a  typical  operating  unit  may  contain  8,000  to  10,000  people  or  even 
more.  It  would  be  needlessly  expensive  to  use  all  of  this  data  in  a  trial 
run  of  a  newly  developed  request.  The  IRIS  system,  therefore,  provides  a 
small  but  representative  sample  of  about  100  individuals  as  a  sample  data 
base  which  is  involved  for  checkout  and  then  replaced  by  the  full  data  base 
for  actual  execution.  A  simple,  one-word  command  accomplishes  each  change. 

4 . 4  Operating  Characteristics 
4.4.1  General 

The  OR  corporate  staff  at  Princeton  has  a  complement  of  approximately 
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80  people.  One  of  the  major  activities  of  this  group  is  the  operation 
of  a  central  Project  Office  which  exercises  technical  and  administrative 
control  over  the  IRIS  system.  In  addition  an  IRIS  "coordinator"  is  lo¬ 
cated  at  each  operating  unit  and  is  responsible  for  introducing  system 
changes,  acting  as  a  "chauffeur"  for  personnel  managers,  and  the  conduct 
of  user  training  programs.  The  Project  Office  itself  monitors  execution 
of  regular  production  runs,  handles  special  requests,  answers  questions 
dealing  with  data  flow  (both  input  and  output),  and  also  serves  as  the 
clearing  house  for  requests  from  user  organizations  for  additional  assis¬ 
tance  in  the  application  of  the  system.  Each  business  making  use  of  this 
system  is  responsible  for  the  preparation  of  its  own  data  for  submission 
to  the  system.  When  a  user  goes  into  a  production  mode,  a  regular  sche¬ 
dule  is  set  for  periodic,  usually  weekly,  updates.  The  user  organization 
must  see  to  it  that  its  transaction  data  are  ready  to  meet  this  update 
schedule.  The  actual  initiation  of  the  scheduled  computer  runs  is  con¬ 
trolled  by  the  central  Project  Office.  Reports  of  changes  made,  errors 
found,  and  other  transaction-related  information  are  sent  back  to  the 
user  organization.  The  user  organization  is  responsible  to  see  to  it 
that  errors  are  corrected  and  that  the  data  base  is  kept  up  to  date  and 
correct. 

Finally,  the  Project  Office  continuously  tests  the  validity  of  the 
data  base  and  periodically,  usually  once  a  year,  f restructures 1  the  system. 
The  necessity  for  restructuring  comes  about  for  a  variety  of  reasons. 

From  time  to  time  some  of  the  users  will  require  additional  data  items  to 
be  kept  in  the  data  base.  During  the  implementation  phase  and  the  early 
use  of  the  system,  these  additional  items  are  accommodated  in  a  special 
sector  within  the  data  base  which  contains  only  locally  useful  data.  If 
a  number  of  users  require  the  collection  of  the  same  data,  then  it  is 
highly  desirable  to  transfer  these  data  items  from  the  local  sector  into 
the  standard  Corporate  sector.  It  may  also  be  necessary  to  expand  appli¬ 
cation  capabilities  or  to  streamline  the  system  to  gain  more  efficiency 
in  updating  or  in  reporting  from  the  data  base.  In  short,  system  restruc- 
turing  serves  the,  purpose  of  keeping  the  system  current  with  changing,  real 
world  requirements. 

4.4.2  Internal  Security 

This  factor  is  generally  the  first  and  foremost  concern  of  managements 
of  operating  units  contemplating  coining  on  to  the  system.  System  and  data 
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security  is  enforced  at  essentially  two  sequential  levels.  The  ’Access1 
password  identifies  individuals  authorized  to  enter  the  system,  and  the 
’Need  To  Know’  password  screens  for  clearance  to  access  specific  portions 
of  the  file,  such  as  that  containing  compensation  inf ormation .  Passwords 
are  frequently  changed  in  conformity  with  corporate  policy  which  recognizes 
the  requirement  for  satisfying  both  the  needs  of  the  operating  unit,  and 
the  corporate  management.  The  system  is  designed  to  have  sufficient 
merit  and  utility  to  be  of  value  to  level  operations,  but  be  able  to  cope 
with  company  wide  issues.  Thus,  the  Corporate  staff  does  not  have  auto¬ 
matic  access  to  the  data  and  reports  of  the  operating  units.  At  the  same 
time,  rigorous  standards  of  data  language  have  been  provided  for  to  assure 
that  all  units  call  each  data  item  by  the  same  name.  Both  Corporate  and 
operating  unit  user  perceptions  of  the  system  have  been  tailored  to  the 
identity  and  responsibility  of  the  user. 

4.4.3  Training 

Taining  is  provided  at  two  levels.  One  is  concerned  with  proper 
preparation  of  input  data,  using  the  codes  and  forms  provided  by  the 
system.  The  other  pertains  to  use  of  the  system  and  is  geared  to  the  non¬ 
computer  oriented  manager.  It  teaches  the  language  of  the  system  to  per¬ 
form  analysis  on  the  data  contained  in  the  data  base.  Originally  train¬ 
ing  for  non-computer  oriented  individuals  began  as  a  one  day  session,  but 
now  has  been  extended  to  a  two  day  program.  The  local  IRIS  ’  coordinator1' 
is  then  available  for  follow-up  instruction  on  a  ad  hoc  basis.  An  elab¬ 
orate  IRIS  User  Guide  of  over  400  loose  leaf  paper  is  available  to  each 
user.  (Copy  available  is  author’s  files) 

4.4.4  On-Line  Evaluation 

Prior  to  full  implementation,  the  Project  Office  estimated  the  costs 
of  operation  based  on  experience  gained  during  the  pilot  implementation 
of  the  system.  As  mentioned  earlier,  one  of  the  unique  features  of  IRIS 
is  that  the  pilot  implementation  served  as  the  initial  version  of  the 
system  under  actual  conditions.  In  the  course  of  this  initial  implemen¬ 
tation,  the  costs  of  operation  were  carefully  collected  to  be  used  in 
making  realistic  projections.  They  were  then  unitized  so  that  they  could 
be  applied  to  other  parts  of  the  Corporation.  A  typical  business  and  its 
operations  were  used  to  arrive  at  a  figure  of  merit  to  be  used  for  esti¬ 
mating  system  cost  for  one  employee  for  one  year.  The  cost  was  calculated 
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to  bo  between  four  and  five  dollars  per  person  per  year.  These  costs 
are  carefuJly  monitored  for  all  IRIS  operations  throughout  the  Corporation. 

In  almost  all  cases,  the  actual  costs  have  been  below  the  initial  estimates 
made.  Actual  cost  experiences  above  initial  estimates  are  attributable  to 
more  extensive  system  use  then  may  have  been  originally  contemplated. 

Figure  5  shows  a  typical  cost  performance  report  for  the  Quarter  September  - 
November  1978  for  each  of  the  major  operating  units.  It  also  reflects  the 
dual  transactional  -  DSS  nature  of  IRIS  x^hich  nox^  approach  average  usage  pat¬ 
terns  of  55%  transactional  and  45%  ad-hoc  DSS.  It  also  indicates  that 
usage  appears  to  be  at  four  levels  enumerated  here  in  approximate  frequency: 

(1)  Ad  hoc  analysis  of  existing  data, 

(2)  Prespecified  aggregations  of  data  (i.e.,  standard  reports), 

(3)  Evaluation  of  consequences  of  proposed  decisions,  and 

(4)  Retrieval  of  isolated  individual  data  items. 

Figure  6  gives  an  example  of  an  ad  hoc  query  by  the  author  of  this  study 
as  to  mHow  many  Georgia  Tech  graduates  x^ork  for  RCA?" 

5 .  EXECUTIVE  INFORMATION  SYSTEMS  (EIS) 

5 . 1  Operational  Environment 

The  First  National  Bank  (Chicago),  or  First  Chicago,  is  a  one-bank 
holding  coproration  with  First  National  Bank  its  principle  asset.  Chartered 
in  1863,  First  Chicago  is  the  oldest  national  bank  in  existence,  and  has 
accumulated  assets  of  over  22  billion  dollars.  Under  Illinois  law,  the  bank 
has  no  branches,  but  operates  primarily  as  a  national  and  international 
commercial  bank  x%rith  installations  in  37  countries,  on  six  continents,  and 
in  most  major  cities  in  the  U.  S.  First  Chicago  has  developed  close  ties  in 
account  relationships  with  Montgomery  Ward,  Sears  Roebuck,  Wm.  Wrigley  Co., 
Inland  Steel  and  Firestone  Rubber,  and  serves  as  registrar  and  transfer  agent 
for  corporate  securities  and  as  underwrit ing  house  for  municipalities. 

Day  to  day  operational  or  tactical  decisions,  are  made  principally  by 
400  Loan  Officers  x^ho  operate  as  P  &  L  managers  with  their  oxm  profit  center. 
These  Loan  Officers  require  data  bases  and  in— depth  analysis  on  60  different 
industrial  sectors  ranging  from  fast  food  branches  to  marine  shipping.  Longer 
range  strategic,  planning,  decisions  are  made  by  committees  from  the  Board 
of  Directors.  A  key  Board  committee  is  the  Asset  and  Liability  Committee 
Xvrhich  sets  the  weekly  rate  for  CDs  and  determines  target  customer  industries. 
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5.2  Major  Events  in  System  Design  Implementation 

In  April  1972,  at  the  instigation  of  Gaylord  Freeman,  a  senior  First 
Chicago  executive,  a  joint  venture  between  IBM  and  First  Chicago  was  initiated 
to  analyze  executive  decision  making  within  the  bank's  organizational  struc¬ 
ture,  and  to  determine  how  a  DSS  might  lend  assistance  to  bank  managers. 

Mr.  Freeman  later  served  as  chairman  of  First  Chicago  from  1974-1975  during 
the  crucial  period  of  IRIS  development.  A  joint  IBM-First  National  team 
was  established,  and  postulated  that  to  identify  viable  alternatives,  it 
would  need  to : 

(1)  Extend  the  data  available  from  the  executives'  computer 
systems  to  include  external  and  internal  information  re¬ 
sources  potentially  available  to  them  in  setting  the  policy 
direction  for  the  institution. 

(2)  Provide  more  sophisticated  techniques  to  evaluate  both 
short-range  and  long-range  growth  and  profit  objectives. 

The  team  further  established  that  the  study  should  consist  of  the 
following  phases: 

(1)  Analyze  the  existing  structure  for  information  flows,  available 
sources  and  current  processes  employed.  This  beginning  phase 
would  describe  decision  supporting  systems  as  they  currently 
existed. 

(2)  Identify  current  deficiencies  in  these  processes,  sources 
and  flows. 

(3)  Recommend  action.  The  makeup  of  the  team  admittedly  lent 
a  bias  toward  an  automated,  computerized  action.  Yet 
the  charter  implied  a  solution  quite  different  from  that 
of  the  application-directed  systems  then  in  existence. 

Prior  to  this  joint  venture,  system  development  activity 
was  aimed  at  automating  clerical  processes  and  providing 
information  for  day— to— day  management.  Reporting  systems 
tended  to  address  the  rather  parochial  needs  of  the  par¬ 
ticular  operating  applications  being  managed.  The  team 
recommendation  clearly  needed  to  address  a  major  change 
in  the  use  of  systems  at  First  National  Bank. 

The  formal  study  began  in  early  1973.  In  the  ensuing  months  the  team 
interviewed  more  than  40  executives  in  sessions  consisting  of  over  300  man¬ 
hours.  The  focus  of  the  study  was  less  on  harnessing  the  power  of  the  com- 
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putcr,  and  more  on  understanding  the  information  needed,  ho w  it  was  used  and 
its  importance  for  decision  making.  Partly  for  the  implicit  understanding 
of  the  decision-making  process  and  to  perhaps  better  leverage  the  combined 
firms’  investment,  the  team  participated  directly  in  analytical  studies  for 
senior  management  during  this  time.  Studies  using  ratio  analyses  of  com¬ 
peting  banks,  evaluating  money  market  liquidity  and  analyzing  commercial 
loan  commitments  were  found  typical  of  those  frequently  requested  by  a 
large  money  center  bank.  The  studies  performed  continued  to  substantiate  the 
inordinate  data-gathering  activities  necessary  to  support  analysis:  86  per¬ 
cent  of  staff  time,  data  gathering:  10  percent  of  staff  time,  analysis,  and 
4  percent  of  staff  time,  formating.  From  the  study  phase,  the  team  concluded 
that  a  mechanism  could  be  designed  to  facilitate  decision  making  and  went 
about  summarizing  its  findings  in  a  manner  suitable  to  suggest  an  interactive 
computerized  approach. 

By  1975  a  prototype  system  had  been  developed  that  utilized  a  decision 
support  module  which  captured  the  revelant  data  related  to  the  fast  food 
franchise  industry,  one  of  sixty  major  industries  of  interest  to  First  Chicag 
An  EIS  staff  of  about  45  people  was  organized  within  the  bank  with  respon¬ 
sibility  for  development,  maintenance  and  application  support  in  new  areas. 

By  the  fall  of  1978,  models  had  been  completed  for  the  remaining  industries, 
and  over  100  of  the  400  loan  managers  were  full  time  users  of  EIS. 

5.3  El S  Architecture 

5.3.1  General 

The  EIS  architecture  is  basically  the  same  as  that  currently  marketed 
by  IBM  as  their  Trend  Analysis/370.  The  system  consists  of  a  terminal  with 
a  keyboard,  light  pen  and  black  and  white  video  screen,  a  color  television 
screen  for  graphics  display,  a  black  and  white  graphics  copier  for  the  TV 
display  and  a  tabular  print-out  device  for  printing  reports  shown  on  the 
black  and  white  video  screen.  Figure  7.  The  terminal  is  interconnected 
to  an  IMS/VS-based  computer  program  as  shown  in  Figure  8.  The  terminals 
are  designed  for  individual  site  installation  in  an  office  sized  room. 
However,  at  the  present  time  there  are  tx<ro  main  conference  room  installations 
each  with  two  terminals,  and  located  on  different  floors  in  the  locale  of  a 
majority  of  the  loan  officers.  There  are  a  few  other  EIS  installations  with 
only  a  display  terminal  and  printer  or  TV. 

5.3.2  Data  Entry 

Data  can  be  entered  into  the  EIS  data  base  either  manually  or  through 
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the  computer,  depending  on  the  form  in  which  the  source  data  is  available. 
If  the  data  is  in  machine-readable  form,  then  it  can  be  entered  into  the 
data  base  using  a  computer  program.  For  example,  if  the  data  is  purchased 
on  a  magnetic  tape  from  an  external  source  or  the  data  is  available  in  the 
Bank's  computers  for  some  other  system  or  application,  then  the  data  can 
relatively  easily  be  entered  into  EIS.  If  the  data  is  not  available  an 
machine-readable  form  and  is  to  be  entered  from  source  documents,  then 
manual  input  is  required.  EIS  provides  data  entry  screens  through  which 
data  can  be  keyed  in.  Frequently,  personnel  from  other  bank  divisions 
assist  in  data  preparation  and  entry.  Depending  upon  the  number  of  data 
elements  being  entered,  eight  to  ten  companies'  information  can  be  entered 
in  one  day. 

5.3.3  Decision  Support:  Nodules 

The  system  employs  a  unique  concept  of  decision  support  modules  and 
menus: 

(1)  Decision  support  modules  (DSMs)  provide  the  basis  for 
establishing  EIS  as  a  utility.  Modules  consist  of  a 
series  of  related  decision  options.  They  are  added 
as  aspects  of  decision  processes  within  the  bank  are 
identified  and  analyzed.  IRIS  architecture  assumes 
that  the  need  for  information  for  decisions  grows  more 
rapidly  than  most  data  systems  can  effectively  provide. 

The  module  acts  like  a  prototype  of  the  decision  pro¬ 
cess.  It  allows  quick  response,  but  more  importantly 
allows  growth  in  concert  with  the  needs  of  management . 

Modules  access  a  common  data  base  and  display  infor¬ 
mation  personalized  to  the  decision  maker Ts  style  and 
patterned  to  the  environment  to  be  managed. 

(2)  Menus  comprise  an  important  aspect  of  EIS.  Modules 

consist  of  sets  of  choices  developed  to  visualize  the 
alternatives  to  be  analyzed  for  the  decision.  The  menus 
enable  the  decision  maker  to  select  from  a  table  of 
earlier  choices  or  to  develop  new  approaches  for  examin¬ 
ing  the  relevant  factors  of  the  decision.  Because  of 
the  menu  concept,  persons  can  become  proficient  in  EIS 
in  little  more  than  one  hour. 
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5.3.4  Comparison  EIS  and  Standard  MIS 

EIS  was  designed  as  an  appendage  to  First  Chicago’s  conventional 
MIS,  and/or  as  a  stand-alone  application.  Figure  9  shows  the  features 
that  EIS  provides. 

Problems  of  MIS  EIS  Features 


(1)  Lack  of  decision  aids 


(2)  Lack  of  compatability 
between  systems 

(3)  Positional  rather  than 
directional  information 

(4)  Wide  separation  of  manager 
and  systems 


(a)  DSMs  distinct  and  unique 

(b)  ad  hoc  math  functions 

(c)  color  graphics 

(d)  stored  formulas,  routines 
reports 

(a)  singular  data  base 

(b)  standard  interface  to  EIS 

(c)  flexible  input  methods 

(a)  time  series  data  base 

(b)  time  function  analysis 

(a)  interactive 

(b)  menu  concept 

(c)  light-pen  sensitive 

(d)  color  graphics 

(e)  personally  controlled 
tabular  lists 

(f)  external  data  available 


Figure  9 

EIS  Features  Compared  to  MIS 


5 . 4  Operating  Characteristics 
5.4.1  Ceneral 

Loan  officers  in  the  Corporate  Banking  Department  are  the  primary 
users  of  EIS  for  aid  in  credit  analysis.  However  applications  have  been 
designed  and  implemented  for  a  number  of  other  users.  The  Bond  Depart¬ 
ment  has  money  market  data  on  EIS,  the  Personal  Banking  Department  (PBD) 
has  savings  and  automatic  teller  system  information  on  the  data  bases, 
and  the  Administrative  Department  also  uses  it.  In  addition  to  this, 

EIS  has  quarterly  Domestic  Call  Reports  and  income  statement  informa¬ 
tion  published  by  the  Federal  Reserve  Bank  for  ten  years  for  413  banks. 
Balance  sheet  and  income  statement  information  for  various  companies  is 
carried  in  EIS.  In  addition,  financial  ratios  have  been  predefined  and 
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are  accessible  with  EIS.  The  First  Chicago/Bond  Department  money 
market  customer  data  base  carries  information  by  various  types  of  lia¬ 
bility  instruments  for  groups  of  customers  aggregated  by  ZIP  codes  and 
SIC  codes.  Personal  Banking  monitors  a  number  of  kinds  of  activity  on 
the  automatic  teller  machine  (ATM)  system.  They  can  examine  individual 
machines  and  isolate  various  transaction  totals  on  a  daily  basis. 

Another  PBD  group  tracks  trends  in  the  savings  and  certificate  of 
deposit  categories  which  are  offered  to  individual  savers.  This  data 
is  transferred,  daily  and  automatically,  from  other  FNBC  computer  sys¬ 
tems. 

Although  the  EIS  has  both  the  software  and  hardware  capabilities, 
there  has  been  relatively  little  usage  of  the  system  by  individuals  of 
the  senior  corporate  staff.  The  Asset  and  Liability  Committee  does  use 
EIS  on  a  weekly  basis  to  make  decisions  on  sales  of  the  bank's  Certifi¬ 
cates  of  Deposit  in  industrial  money  markets.  However  most  of  the  users 
are  lower  middle  management  who  had  had  experience  with  computer  tech¬ 
nology  in  their  academic  careers. 

5.4.2  Internal  Security 

Data  stored  in  the  EIS  data  base  is  secure  and  protected  from 
unauthorized  usage.  Each  EIS  user  area  is  assigned  an  EIS  number  which 
identifies  the  user  and  the  application  he  will  use.  In  addition,  there 
is  a  password  protection.  Associated  with  each  EIS  number  is  a  password 
known  only  to  the  users  of  EIS  in  that  area,  and  the  system  can  be 
accessed  only  if  the  correct  password  is  supplied.  In  addition,  the 
sign-on  codes  and  data  in  the  data  bases  can  be  arranged  so  that  a 
number  of  users  can  have  access  to  most  of  the  data  but  any  individual 
user  can  protect  certain  private  data  from  access  by  anyone  but  himself. 
All  the  data  resides  on  FNBC f s  computers  which  are  protected  by  the 
Bank's  security  force  24  hours  a  day,  and  the  EIS  data  can  be  accessed 
only  through  special  terminals  connected  to  FNBC ! s  computers.  Access 
requires  a  knowledge  of  equipment,  sign-on  codes,  and  passwords. 

5.4.3  EIS  Application  Development  Cycle 

The  EIS  staff  unit  is  responsible  for  the  development,  maintenance, 
and  application  support  of  EIS.  EIS  has  been  developed  in  a  fashion 
which  makes  the  addition  of  new  users  relatively  easy. 
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A  typical  application  installation  cycle  is  as  follows: 

(L)  A  demonstration  of  EIS  to  the  user. 

(2)  Expression  of  interest  in  the  use  of  EIS  in  the  user’s  area. 

(3)  User  department  and  EIS  personnel  make  an  analysis  of  the 
information  needs  and  identify  potential  areas  for  EIS 
application. 

(4)  An  analysis  and  specification  of  the  desired  system,  with 
user  participation,  i.e.,  sources  of  data,  organizations  to 
be  included,  data  elements,  time  periods,  frequency  of  the 
data,  method  of  data  entry. 

(5)  Creation  of  menus,  data  base  entries,  and  data  entry  programs. 

(6)  User  education. 

(7)  User  usage. 

(8)  After  gaining  experience  with  the  system  and  learning  the 
power  of  EIS,  the  user  generally  expands  and/or  redesigns 
the  current  application. 

(9)  Change  of  the  current  application. 

5.4.4  Cost  and  Operational  Evaluation 

Costs  for  EIS  are  borne  by  the  users  on  an  internal  fund  transfer. 
Initial  programming  of  an  application  costs  about  $1000  with  training 
and  educational  costs  estimated  at  $200.  Operating  costs  are  about  .10 
per  transaction  or  about  $3.00  per  report. 

6 .  WORLD  WIDE  INFORMAT ION  SYSTEM  (WINS) 


6 . 1  Operational  Environment 

The  Gould  Corporation  is  a  medium  size  international  conglomerate 
primarily  a  manufacturer  of  electronic  products  whose  sales  have  grown 
from  $350  million  in  1969  to  over  $1.6  billion  in  1977  under  the  leader¬ 
ship  of  W.  T.  Ylvisaker  who  is  currently  CEO  and  Chairman.  Gould  manu¬ 
factures  over  twenty  product  lines,  and  operates  with  forty  field  divi¬ 
sions,  each  responsible  for  their  own  planning,  operations  and  profit 
center.  Gould’s  products  range  from  automobile  batteries,  electric 
motors  to  the  manufacture  of  copper  foil.  Over  45,000  employees  are 
managed  by  a  corporate  staff  of  450  located  at  Rolling  Meadows,  near 
Chicago.  In  a  decentralized  management  mode,  each  field  division  is 
responsible  for  its  cm  MIS  system  for  planning  and  operations.  The 
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principle  management  tool  used  by  corporate  headquarters  is  a  monthly 
core  report  which  sets  objectives,  resource  allocations,  and  performance- 
criteria  for  each  profit  center.  This  core  report  plus  a  weekly  status 
report  are  the  basis  for  the  majority  of  corporate  decision  making. 

Mr.  Werner  Menck,  director  of  financial  analysis,  played  a  major  role 
in  developing  the  performance  measures  and  format  for  the  core  report. 

6 . 2  Major  Events  in  WINS  Development-Implementation  Cycle 

In  1972  Mr.  Ylvisaker  commissioned  an  outside  consultant  to  build 
a  "war  room”  for  use  by  the  senior  corporate  executives  which  would  pro¬ 
vide  graphic  displays  of  information  needed  for  high  level  strategic 
planning  sessions  which  would  display  different  representations  of  all 
data  in  the  monthly  core  report.  By  1974  dual  facilities  had  been 
installed  in  the  corporate  board  room  at  Gould  headquarters  in  suburban 
Chicago,  and  in  an  adjacent  location  at  Gould  Center  devoted  to  manage¬ 
ment  training  programs.  These  facilities  included  a  complete  audio¬ 
visual  system  with  a  large  rear-projection  TV  screen,  and  were  capable 
of  displaying  four-color  graphs  and  charts  in  slide  form.  The  audio¬ 
visual  system  was  equipped  with  an  elaborate  control  panel  for  the  rapid 
sequencing  of  displays  according  to  the  chairman fs  dictates.  However 
the  early  version  was  incapable  of  directly  interacting  with  a  computer¬ 
ized  data  base  system,  and  required  a  large  amount  of  manual  processing 
of  data.  In  October  1975  Mr.  Menck  was  assigned  to  head  a  project  team 
which  was  assigned  to  solve  the  software  interface  problem  to  present 
on-line  graphics  from  the  computer  data  base  on  an  ad-hoc  basis.  By 
early  1977  the  board  room  system  was  completely  operational.  The  WINS 
also  included  six  small  screen  black  and  white  TV  type  displays  which 
were  designed  for  use  by  selected  corporate  managers  as  a  deck  mounted 
aid  for  decision  making  on  a  day-to-day  basis  outside  of  the  weekly 
board  room  use. 

6.3  Architecture 


6.3.1  General 

The  overall  WINS  hardware  configuration  is  centered  around  a 
PDP11/35  minicomputer  located  at  Gould  headquarters  which  interfaces 
with  a  remote  Burroughs  6700  mainframe  at  the  company's  regional  center 
in  Cleveland.  The  PDPll/35  feeds  a  Ramtek  converter  that  drives  a 


29  - 


WINS 


HARDWARE 


CONFIGURATION 


(Office  use) 


(Boardroom  use) 


Figure  10 


/ 


General  Electric  light  valve  which  projects  onto  the  large  screen  board 
room  display.  To  display  numerical  data  the  Ramtek  converter  is  by¬ 
passed.  The  six  desk  top  terminals  are  slaved  to  the  system  with  both 
coaxial  cable  and  transmission  wire.  The  whole  configuration  including 
ancillary  peripheral  equipment  is  shown  in  Figure  10. 

6.3.2  Data  Management 

Although  each  division  maintains  its  own  computer  systems  for 
management  and  manufacturing,  the  company  maintains  a  regional  computer 
center  at  Cleveland.  As  part  of  normal  monthly  closings  all  division 
financial  data  is  fed  into  a  central  financial  data  base  at  the  regional 
center.  The  data  base  is  structured  so  as  to  provide  data  for  the 
monthly  core  report  which  is  produced  and  published  for  management  by 
the  corporate  staff  on  the  tenth  working  day  after  the  close  of  each 
month.  As  the  update  data  files  are  transmitted  to  Chicago,  they  are 
also  recorded  on  a  magnetic  tape  for  input  to  the  PDP11/35. 

6.3.3  User  Interfaces 

WINS  was  originally  designed  principally  for  board  room  use  by  the 
CEO  and  the  senior  corporate  managers  as  a  "control”  rather  than  "plan¬ 
ning"  decision  aid.  In  the  "control"  mode  the  emphasis  was  on  group  or 
consensus  review  of  data  in  graphic  or  tabular  format  which  represented 
the  current  state  of  division  operations.  As  the  system  evolved  more 
emphasis  was  placed  on  the  use  of  corporate  models  for  asking  "what  if" 
questions  related  to  planning  functions  than  an  individual  management 
might  be  interested  in.  The  six  desk  type  terminals  were'  designed  to 
be  strategically  located  through  the  senior  management  office  area  so 
that  either  the  individual,  or  perhaps  groups  of  one  or  two  senior 
managers  might  begin  to  use  the  terminals  in  much  the  same  way  they 
used  a  telephone  or  an  administrative  assistant  or  a  secretary.  Based 
on  some  simple  human  factors  considerations  the  following  principles 
were  incorporated  into  the  WINS  design: 

(1)  Relatively  small  amounts  of  input  required  (ten-digit 
maximum  for  any  selection). 

(2)  Instantaneous  response  (usually  in  eight  seconds  but  no 
more  than  80  seconds). 

(3)  Screen  must  present  all  the  information  at  one  time  for 
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in  form  at  mm  ip:mn  index 


ORGAN  1 7  ATI  ON  UNIT  INDL  X 
(TIRST  3  DIGITS) 


(second  3  tapirs 


Consol idated 

CON  or  266 

Automotive  Battery 

ABD  or  223 

IBD-Cjtudd 

IDC  or  422 

Industrial  Battery 

IDD  or  423 

Metals 

MET  or  638 

Plastics 

PLS  or  757 

Portable  Battery 

P0D  or  723 

Battery 

BAT  or  228 

Electric  Systems  RXD 

ELS  or  357 

Electric  Systems  Sales 

ESS  or  377 

Power  System 

PDW  or  769 

Switchgear 

SWI  or  794 

Insulator 

ISL  or  475 

ITE  Industries-Austral ia 

AUS  or  287 

Electrical  Sys. 

ESG  or  374 

Circuit  Protection 

CRT  or  278 

Controls 

CSY  or  279 

Electric  Fuse 

EFD  or  333 

Electric  Heat 

HED  or  433 

Electric  Motor 

EMD  or  363 

Electrical  Apparatus 

APP  or  277 

Electrical  Components 

ECD  or  326 

Sales 

SAL  or  725 

Electric  Products 

ELE  or  353 

Elastomer  Products 

ELA  or  352 

Engine  Parts 

EPD  or  373 

Foi  1 

FDI  or  364 

Foundry 

FDY  or  339 

Powder  Metal 

PMD  or  763 

Industrial 

IND  or  463 

Fluid  Components 

CMP  or  267 

Hose  &  Coupl ings 

HCP  or  427 

Valve  &  Fittings 

VFD  or  833 

Fluid  Power 

FLG  or  354 

Biomat  ion 

BIO  or  246 

Electronic  Components 

ADV  or  233 

Instrument  Systems 

ISD  or  473 

Mod  icon 

MCC  or  622 

Nucleonic  Data  Systems 

NDS  or  637 

Measurement  Systems 

MEA  or  632 

Instrument  &  Controls 

ICG  or  424 

Contardo 

CNT  or  268 

Chesapeake  Instruments 

CHS  or  247 

Electronic  Systems 

SYS  or  797 

Hydrosystems 

HSY  or  497 

Dcean  Systems 

OSD  or  673 

Government  Systems 

GOV  or  468 

WEEKLY  STATUS  ITEMS 

Receivable  Days 

BET  or  238 

Inventory  Days 

FUN  or  386 

Payable  Days 

PAD  or  723 

Order  Backlog 

CAT  or  228 

Orders  Received 

DOG  or  364 

Met  Sales 

SEX  or  739 

Receivable  $ 

DUE  or  383 

Inventory  $ 

MUD  or  683 

Payable  $ 

PET  or  738 

Overtime  $ 

VUE  or  883 

Working  Capital 

CAP  or  227 

Division  Total 

TDT  or  868 

Groups  Broken  Down  by  D i v i s 1 o n 

BCD  Battery 

ESY  Electrical  Systems 

EGD  Electrical  Products 

IGD  Industrial 

FLU  Fluid  Power 

IXD  Instrument  &  Controls 

USG  Government  Systems 

Tota 1  Broken  Down  by  Group 

TBG  Total  Corp.  by  Group 


C  -  Consol idated 

T  -  Total  of  Divisions  (not  consolidated) 
G  -  Group 
D  -  Di vis  ion 

*  Indicates  the  item  has  Forecast  Data 


f  *  i,  items 

Fu  1  r~ V  ».  L  Show i  ng  All  Major 
Lino  l  terns  IC,T,G,D) 

Cross  Sales-Externa  l 
<T,0,l>) 

Gross  Salcs-I'.itorco.  (T.C,D) 
Sales  Deduct  Loris  (T,C,D) 

Net  Sales  (T,G,D) 

Cost  of  Goods  Sold  (T,G,D) 
Gross  Profit  <T,C,D) 
Engineering  (T#G,D) 

R  fc  D  (T,G ,D) 

Advertisirftf  (T,C,D) 
Distribution  (T,G,D) 

Guarantee  (T,G, D) 

Other  Marketing  (T,C,D) 

Total  Marketing  (T,G,D) 
Administrative  (T,G,D) 

Other  Expenses  (7,  G,  D) 

Other  Income  (T,G,D) 

Export  Incentive  (T,G,D) 
Leasing  Incentive  (7,G,D) 
Corporate  Allocation  (T,G,D) 
PBT  (T,G,D) 

Balance  Sheet  Items 

Full  Consolidated  Balance 
Sheet  (C) 

Full  Net  Assets  Employed 
Showing  All  Major  Line 
Items  (T,G,D) 

Accounts  Rec. -Total  (T,G,D) 
Accounts  Rec. -Overdue  (T,G,  D) 
Inventory  -  Materials  (T,G,D) 
Inventory  -  W.I.P.  (7,G,D) 
Inventory  -  Fin.Gds.  (T,G,D) 
Inventory  Reserves  (T,G,D) 
Inventory  Total  <T,G,D) 
Accounts  Payable  (T,G,D) 
Working  Capital  (T  ,G  ,D) 

Net  Fixed  Assets  (T,C,D) 

Net  Assets  Employed  (T,G,D) 

Ratios  and  Other  Item s 


PRO  or  776 

SOX  or  76') 
SIN  or  746 
SON  or  7t>G 
SEX  or  7  39  * 
COY  or  269 
BAG  or  224 
SIT  or  748 
WOW  or  969 
TIN  or  846 
FEW  o *r  339 
SID  or  743 
BIN  or  246 
SUE  or  703 
ANN  or  266 
WON  or  966 
SUN  or  706 
BUN  or  286 
TON  or  066 
TOW  or  369 
FIN  or  346  * 


GIN  or  446 


NET  or  638 
DUE  or  383  * 
PER  or  737 
RAW  or  729 
WED  or  933 
LED  or  533 
SEE  or  733 
MUD  or  60  3  * 
PET  or  738  * 
CAR  or  227  * 
FIX  or  349  * 
FAT  or  328  * 


Net  Cash  Flow  (T,G,D)  MAY  cr  629 

Capital  Expenditures  (T,C,D)  ram  or  726 


Orders  Received  (T,G,D) 

DOG 

or 

364 

Order  Back  Log  (T,G,D) 

CAT 

or 

228 

Export  Sales  (T,G, D) 

SAG 

or 

724 

Total  Employees  (T,G,D) 

DUG 

or 

384 

Manufacturing  Employees  — 

Direct  (T,G,D) 

CAN 

or 

226 

Manufacturing  Employees  -  . 

Indirect  (T,G, D) 

IA? 

or 

527 

Salaried  Employees  - 

Exempt  (T,G,D) 

TAG 

or 

824 

Salaried  Employees  - 

Non-Exempt  (T,G,D) 

FAN 

or 

326 

Avg.  Hourly  Wage  (T,G,D) 

DOE 

or 

363 

Index-Selling  Price  (T,G,D) 

MOD 

or 

663 

Index-Raw  Material  (T,G,D) 

TAN 

or 

826 

Index-Purchased  Parts  T,G,D) 

LUG 

or 

504 

Index-Direct  Labor  (T,G,D) 

MAT 

or 

620 

Index- IME  (T,G,D) 

RAT 

or 

728 

Variance-Selling  Price (T,G,D) 

TUG 

or 

004 

Variance-Sales  Voluma  (T,G,D) 

OLD 

or 

653 

Variance-Sales  Mix  (T,G.D) 

RUG 

or 

734 

Variance-Cost  (T ,G , D) 

LET 

or 

530 

Gross  Profit/Net  Sales  (C,T  ,G  ,D>BOP 

or 

267 

PBT/Net  Sales  (C,T,G,D) 

LAW 

or 

529 

• 

PBT/Net  Assets  Employed <T,G,D)CUB 

or 

202 

Working  Capital/Net  Sales  (C) 

FOX 

or 

369 

Net  Assets  Employed/ 

Net  Sales  (T,G,D) 

PAP 

or 

727 

Accts.  Rcc.  Days  (C  ,T  ,G  ,D) 

BET 

or 

23B 

* 

Inventory  Days  (C,T,G,D) 

FUN 

or 

306 

* 

Accts. Payable  Days  (C,T,G,D) 

PAD 

or 

723 

* 

Sales  Pec  Employee  (C,T,C,D) 

CAY 

or 

429 

Profit  Per  Employee (C,T,G ,0) 

JOB 

or 

562 

Fixed  Assets  Per  Employee (C) 

GOT 

or 

468 

Total  Assets  per  Employee (C) 

BUG 

or 

204 

PAT/Net  Sales  (C) 

DAD 

or 

323 

PAT  Total  Assets  <C) 

TOE 

or 

863 

PAT/Equity  (C) 

FED 

or 

333 

Tax  Fate  (C) 

SOT 

nr 

768 

Cni^k  °at io  (C) 

MOP 

or 

667 

Curient  Ratio  (C) 

VAT 

or 

828 

Liar.il  it  ics/Equity  (C) 

TAP 

or 

827 

NT.*./ LTD  (C) 

ELM 

or 

356 

Li'D/OapL tal  L nation  (C) 

OAK 

or 

625 

Total  Duht/Capitali.-.atLoit  (C) 

JOT 

or 

56H 

forecast  Data 

FOR  or  367 

Figure  11.  WINS  Directory 


any  single  report.  Column  of  numbers  on  the  hard  copy 
report,  familiar  to  the  managers  are  presented  in  the  same 
order  on  the  screen. 

(4)  Menu  display  must  be  simple. 

The  first  principle  resulted  in  the  design  of  a  10  button  "princess 
telephone"  type  entry  device  connected  to  the  desk  top  TV  screen  which 
in  itself  was  consistent  with  the  manager's  normal  usage  of  the  telephone. 
The  only  additional  control  at  the  desk  top  terminal  was  a  three  way 
switch  mounted  on  the  chassis  of  the  TV  monitor. 

6.3.4  Software  Programs 

A  user  of  WINS  is  capable  of  calling  up  five  types  of  information 
from  the  core  report,  and  to  use  four  types  of  corporate  models  for 
analysis  and  planning.  The  five  versions  of  the  core  report  are: 

(1)  Financial  Information  (This  program  enables  the  user  to 
call  individual  items  of  information  using  a  directory  of 
available  items  and  units  which  shows  individual  identifi¬ 
cation  codes  -  Figure  11.) 

(2)  Fixed  Information  Items  (Similar  to  first  program  except 
it  is  designed  to  eliminate  the  need  for  repeated  keying 
in  the  same  information  item  when  a  series  of  displays  of 
the  same  item  is  shown  for  a  variety  of  different  units.) 

(3)  Fixed  Organization  Unit  (Similar  to  second  program  except 
designed  to  eliminate  the  need  for  repeated  keying  when 
all  information  is  requested  for  a  single  unit.) 

(4)  Exception  Analysis  and  Display  (This  program  allows  the 
quick  determination  of  trouble  areas  and  permits  the  analy¬ 
sis  and  segregation  of  only  those  items  that  indicate 
unfavorable  performance  against  the  planned  objective.) 

(5)  Exception  Display  Only  (This  program  keeps  in  memory  the 
last  exception  display  analysis  that  was  prescribed  and 
eliminates  the  need  for  cycling  through  the  Exception 
Analysis  and  Display  sequence.) 

Five  types  of  corporate  models  have  been  planned  for  incorporation 
into  WINS  software  programs: 

(1)  Break-Even  Analysis  Model  (Is  currently  operational  and 
performs  various  standard  break-even  and  profitability 
calculations . ) 
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(2)  Sales  Growth  Model  (Is  currently  operational  and  determines 
the  sales  growth  rate  that  can  be  financed  per  a  prescribed 
set  of  assumptions  for  working  capital  and  fixed  capital 
requirements,  return  on  sales,  leverage  and  dividend  payout.) 

(3)  Source  of  Profits  Model  (Is  currently  operational  and  is 
used  to  analyze  the  source  of  a  company's  profit.) 

(4)  Stockholder  Return  Model  (Being  reprogrammed,  not  practical^ 
to  use  in  present  form.) 

(5)  Earnings  Growth  Model  (Being  reprogrammed,  not  practical  to 
use  in  present  form.) 

6.4  Operational  Characteristics 

6.4.1  General 

In  recent  months  usage  of  WINS  has  generally  fallen  off,  both  in 
the  board  room  and  in  the  office  terminal.  WINS  has  not  had  any  sig¬ 
nificant  influence  on  the  management  style  of  the  senior  corporate 
managers.  According  to  Mr.  Menck  this  trend  is  due  to  three  factors: 

(1)  The  CEO  is  color  blind,  and  the  system  has  been  unable  to 
adapt  to  his  changing  interest  and  personnel  information 
needs. 

(2)  The  senior  executives  seldom  get  together  in  each  other's 
offices,  and  most  of  them  as  individuals  have  not  built  up  a 
trust  in  the  use  of  interactive  computer  systems. 

(3)  Hard  copy,  as  personified  in  the  printed  "core  report"  is 
more  desirable  and  reliable.  (Most  active  users  are  young 
executives  who  used  computers  in  their  college  courses.) 

6.4.2  Internal  Security 

Security  for  WINS  is  relatively  simple  since  there  are  only  a 
small  number  of  terminals  and  users  who  are  all  located  in  one  general 
office  area.  Since  the  system  is  a  computerized-graphic  version  of  the 
"core  report"  it  accords  the  same  level  of  classification.  The  Gould 
Company  has  an  "open  door"  philosophy  towards  its  management  system 
and  operational  data,  and  the  core  report  receives  a  wide  distribution 
through  the  organization.  However  each  user  does  have  a  5-digit  pass¬ 
word  to  allow  him  access  to  a  program  menu  and  use  of  WINS. 
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6.4.3  Trairviri^ 

Virtually  no  training  is  necessary  to  operate  the  WINS  terminal. 

Aside  from  normal  TV  type  controls  for  Scan  Size,  Contrast  and  Bright, 
the  user  need  only  use  the  telephone  like  push  button  box  in  response 
to  menu  offerings.  One  needs  only  a  directory  of  the  type  shown  in 
Figure  11  and  a  13  page  memo  which  describes  six  data  sources  and  six 
analytical  models. 

7.  GEO -DATA  ANALYSIS  AND  DISPLAY  SYSTEM  (GADS) 

7 . 1  Operational  Environment  and  Major  Events 

GADS  development  was  initiated  in  the  early  1970’ s  by  the  IBM 
Research  Laboratory  in  San  Jose,  California  as  part  of  a  research  pro¬ 
gram  to  study  the  use  of  DSS  by  non-programmers  to  solve  unstructured 
problems  effectively.  The  program  focused  on  the  solution  of  problems 
involving  data  which  could  be  related  to  geographical  locations.  Unlike 
IRIS,  EIS,  and  WINS  the  objective  of  the  GADS  project  was  to  understand 
the  process  of  user-computer-aid  graphics  decision  making,  both  in  the 
individual  and  in  the  group  consensus  modes  of  operation.  From  the 
beginning  GADS  was  regarded  as  an  experimental  research  effort  and  not 
as  a  development-implementation  effort  to  meet  specific  user  require¬ 
ments.  Most  of  the  funding  for  GAD S  development  was  provided  from  IBM’s 
own  internal  research  program.  This  emphasis  is  reflected  in  the  number 
of  research  papers  that  have  appeared  in  the  literature.  A  majority  of 
these  papers  have  focused  on  the  problems  of  training  managers  or  other 
professionals  as  DSS  users,  or  on  the  more  academic  problems  of  evalua¬ 
tion  and  design  methodologies.  Although  the  basic  GADS  configuration 
has  never  been  institutionalized  in  any  specific  organization,  the  IBM 
research  group  has  made  extensive  contributions  to  DSS  technologies  in 
general.  For  example,  the  consent  of  a  skilled  intermediary  or 
"chauffeur"  came  from  the  IBM  group.  This  "integrating  agent"  acted 
as  1)  an  "exegetist"  who  explained  the  DSS  to  the  user,  2)  a  "crusader" 
who  sold  the  system  through  personal  enthusiasm,  3)  a  "confidant"  who 
built  up  the  user’s  self-confidence  and  acted  as  an  advisor,  and  4)  a 
"teacher"  who  provided  personalized  instruction. 

By  early  1973  IBM  researchers  recognized  the  need  for  a  field 
laboratory,  and  established  a  working  agreement  with  a  local  governmental 
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agency,  the  Center  for  Urban  Analysis  in  Santa  Clara  County,  California 
(San  Jose  is  the  major  city  in  this  county).  Fortuitously  in  1973  the 
Center  for  Urban  Analysis  received  a  LEAA  grant  for  research  in  the 
criminal  justice  area,  and  the  San  Jose  Police  Department  faced  a  major 
problem  in  developing  a  more  efficient  manpower  deployment  system  for 
the  schedule  of  police  beats.  The  existent  scheme  had  been  devised  in 
1965  and  was  unable  to  cope  with  rapid  population  growth  and  geographi¬ 
cal  relocations  which  resulted  in  high  workload  areas,  unstructured 
field  patrols,  backlogs  for  police  service  and  an  unhappy  public.  A 
joint  services  agreement  was  established  between  the  Police  Department 
and  IBM  researchers  with  the  Center  acting  as  a  conduit  for  federal 
funds  and  a  certain  amount  of  technical  support.  Other  similar  joint 
services  agreements  were  established  in  the  San  Jose  area  which  provide 
that  IBM  would  provide  free  computer  time,  software  support,  and  tech¬ 
nical  support  for  system  modification  with  other  public  service  agencies 
Although  no  major  functional  changes  have  been  made  in  the  GADS  con¬ 
figuration  since  June  1974,  the  research  program  has  resulted  in  over 
16  different  applications,  and  experience  with  the  training  of  over  200 
users  with  no  previous  experience  with  computer  systems.  GADS  has 
evolved  as  an  experimental  general  purpose  DSS  for  computer-aided  deci¬ 
sion  making  in  the  public  sector.  Roughly  one  third  of  the  applications 
were  in  the  police  field,  one  third  in  the  social  field  related  to 
redefining  school  district  boundaries,  planning  for  urban  growth,  etc., 
and  the  remainder  in  such  diverse  areas  as  establishing  fire  protection 
districts.  The  sole  non-public  sector  application  was  the  internal  IBM 
application  to  the  problem  of  assigning  service  territories  to  customer 
engineers.  This  last  system  was  designed  for  use  by  Field  Managers 
(first  level  managers)  in  IBM’s  Office  Product  Division. 

7 . 2  Architecture 
7.2.1  General 

GADS  is  a  computerized  interactive  graphics  system  that  essentially 
draws  maps  which  provide  decision  maker (s)  with  tools  for  analyzing  data 
categorized  in  terms  of  geographic  coordinates.  There  are  no  sophisti¬ 
cated  operations  research  models  or  statistical  software  packages  avail¬ 
able  to  the  user.  The  system  is  designed  to  provide  a  data  abstraction 
and  presentation  language  in  a  multitude  of  colors  to  aid  a  user  in 
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Display 


Figure  12 
GADS  Architecture 
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spatially  oriented  resource  allocation  problem  solving.  The  basic  GADS 
architecture  required  complex  data  management  software  and  data  prepara¬ 
tion  which  was  provided  by  IBM  in  the  experimental  applications  until 
1976.  Major  changes  had  to  be  made  prior  to  operational  use  by  public 
sector  agencies  to  provide  for  programming  support  and  maintenance. 

After  1976  most  of  the  15  experimental  applications  in  the  public  sec¬ 
tor  were  phased  out  or  extensively  modified.  The  San  Jose  police  adap¬ 
tation  of  the  original  GADS  represents  the  closest  generic  variation, 
and  successful  operational  system. 

The  GADS-Police  Beat  application  is  also  a  good  example  of  the 
problems  of  designing  the  proper  balance  between  a  data-oriented  system 
and  a  model-oriented  system.  In  the  initial  stages  of  development  it 
was  decided  that  a  heavily  data-oriented  would  provide  a  better  alterna¬ 
tive  than  the  then  existing  manual  and  heuristic  scheme  for  allocating 
police  manpower  to  areas  (beats).  Reports  were  generated  on  police 
calis-for-service,  workload,  response  times,  etc.  The  relevant  data 
was  plotted  manually  on  maps,  and  police  management  used  the  maps  to 
develop  and  evaluate  alternative  decisions.  The  result  was  an  alloca¬ 
tion  plan  which  was  more  expensive  and  farther  from  the  quantitative 
objectives  (e.g.,  balanced  workload)  than  the  existing  scheme.  Next, 
an  operations  research  consultant  was  asked  to  help  make  the  decision 
using  a  model-oriented  DSS  to  determine  an  ’‘optimal"  plan.  The  con¬ 
sultant  interviewed  decision  makers,  developed  objective  functions, 
collected  the  "relevant"  data,  developed  an  allocation  model,  and  ran 
the  model  to  make  the  decision.  The  resulting  plan  was  rejected  by 
police  management  because  it  violated  several  qualitative  objectives 
which  could  not  be  incorporated  into  the  model.  Finally  a  DSS  of  the 
type  shown  in  Figure  12  was  provided  for  the  decision  makers.  The  DSS 
was  used  by  the  decision  makers  to  develop  a  manpower  allocation  plan, 
a  variation  of  which  is  still  in  use.  Consequently  our  focus  in  look¬ 
ing  at  the  GADS  architecture  and  operational  characteristics  will  center 
primarily  on  the  Police  Beat  application. 

7.2.2  System  Software  and  Hardware 

The  basic  GADS  architecture  is  shown  in  Figure  12  and  reflects  the 
emphasis  on  and  the  complexity  of  data  management  software  and  data 
preparation.  The  experimental  GADS  implementation  was  in  FORTRAN, 
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using  IBM’s  Graphic  Subroutine  Package.  The  system  runs  on  an  IBM 
360/195  under  the  OS/MVT  operating  system  and  Time  Sharing  Option  (TSO) . 
The  system  requires  175  bytes  of  main  storage,  and  it  has  been  run  on  an 
IBM  360/50.  The  user  terminal  is  an  IBM  2250-3,  a  refreshed  CRT  with 
vector  graphics  and  character  generation.  The  user  interacts  with  the 
display  using  a  light  pen,  an  alphanumeric  keyboard,  and  a  programmed 
function  keyboard.  The  extracted  data  base  is  stored  on  disk. 

7.2.3  GADS  Data  Extraction 

The  basic  GADS  architecture  as  shown  in  Figure  12  reflects  the 
importance  of  data  management  software  and  data  preparation,  as  well  as 
a  color  display  terminal  with  a  high  resolution  capability  with  minimum 
flicker  (in  excess  of  1024  x  1024  characters).  GADS  data  extraction  is 
a  process  whose  inputs  are  a  set  of  source  data  files,  a  Geographic  Base 
File  (GBF)  containing  computerized  maps,  and  an  aggregation  and  subset¬ 
ting  specification,  and  whose  output  is  an  on-line,  extracted  data  base. 
Each  source  record  contains  a  geographic  code  (such  as  an  address)  so 
that  extracted  data  can  be  related  to  points,  lines,  or  polygons  on  a 
computerized  map.  A  detailed  base  map  in  the  GBF  is  used  during  extrac¬ 
tion  to  transform  the  geographic  codes  in  the  source  file  records  into 
geographic  (x,  y)  coordinates.  Special  purpose  maps  (such  as  a  set  of 
zone  outlines)  are  then  used  for  aggregations  of  the  data.  To  keep  the 
GBF  accurate  and  to  enter  the  special  purpose  maps  required  for  each 
application,  a  GBF  "create-and-modif yM  program  provides  crucial  support. 

GADS  users  supply  a  list  of  source  files,  data  names  (logical  and/ 
or  arithmetic)  for  any  combinations  required  to  select,  aggregate,  or 
compute  data  for  an  extracted  data  base.  In  the  Police  Beat  example 
shown  in  Figure  12,  an  extracted  data  base  for  crime  analysis  is  formed 
from:  source  files  containing  10  years1  data  on  crimes,  land  use,  and 

population;  a  special  purpose  map  of  police  beat-building-blocks  (basic 
zones);  and  an  extraction  specification  for  computing  20  crime  categories 
and  selecting  population  and  number  of  houses  by  year-  The  result  is  10 
tables  (one  for  each  year)  giving  crime  by  category,  population,  and 
number  of  houses  for  each  basic  zone. 

A  totally  integrated  data  base  of  source  files  is  an  alternative 
to  an  extracted  data  base  and  would  eliminate  redundancy  between  the 
extracted  data  and  the  source  files.  This  alternative  was  rejected 
because : 


39 


(a)  aggregation  and  subsetting  would  have  to  be  performed 
dynamically; 

(b)  for  any  application  all  the  relevant  source  files  would 
have  to  be  on-line  to  support  conversational  GADS  use; 

(c)  protection  of  the  source  files  would  be  more  difficult; 

(d)  GADS  would  be  dependent  on  the  existence  of  an  integrated 
data  base. 

7*2.4  GADS  Analysis  and  Display  Functions 

GADS  embodies  two  important  design  goals  for  the  analysis  and 
display  functions.  First,  the  functions  should  support  a  set  of  appli¬ 
cations  using  geographic  data.  Second,  the  functions  should  be  powerful 
enough  to  meet  the  data  manipulation  requirements  of  users  who  are  appli¬ 
cation  specialists,  but  simple  enough  so  that  each  function  could  be 
learned  in  a  few  minutes.  To  achieve  these  two  goals  the  following 
strategies  are  used.  The  analysis  and  display  functions,  chosen  on  the 
basis  of  our  study  of  potential  applications,  are  presented  as  a  set  of 
major  functional  groupings  which  the  user  can  learn  and  invoke  depending 
on  his  problem  requirements  and  his  solution  approach.  Within  each  group¬ 
ing,  functions  are  divided  into  levels.  A  user  can  progress  from  the 
basic  levels  to  the  more  complex  during  problem  solution.  Data  storage 
and  display  in  terms  of  maps  serves  as  a  natural  framework  for  unifying 
the  functions.  The  five  major  groups  of  functions  are: 

(1)  Statement  Language  which  essentially  provides  command  language 
to  users  for  saving,  editing,  calling  up  data  elements,  invoking 
dynamic  aggregation,  etc. 

(2)  Map  Display  which  support  display  of  statement-created  sym¬ 
bols  on  map,  change  scale  and  display  zone  numbers  and  data 
values  for  any  symbol. 

(3)  Overlay  Construction  which  provide  ability  to  create  overlay 
maps  or  save  maps  in  library. 

(4)  Graphs  are  a  second  method  of  display  for  one,  tx^o  or  three 
dimension  with  automatic  or  manual  axes  scaling. 

(5)  Table  Display  and  Correction  provides  a  third  display  mode 
and  method  of  correction. 
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7 . 3  Operational  Characteristics 


7-3.1  Security  and  Evaluation  of  Public  Sector  Systems 

Internal  security  for  either  users  or  data  storage  has  not  been 
a  major  concern  in  the  public  sector  applications  of  CADS.  Nor  has  cost/ 
effectiveness  or  on-line  evaluation  since  most  of  the  individual  appli¬ 
cations  were  funded  from  federal  or  IBM  research  funds.  Extensive  efforts 
were  made  to  determine  the  value  of  the  CADS  Police  Beat  system;  per  se. 

In  both  interviews  and  questionnaires  the  police  officers  unani¬ 
mously  responded  that  using  GADS  improved  their  understanding  of  the 
beat  structuring  problem  and  resulted  in  a  better  solution  than  would  have 
been  obtained  from  alternative  approaches.  The  officer  acceptance  of  the 
GADS  solution  was  in  contrast  to  their  earlier  rejection  of  an  "operations 
research"  solution  which  a  consultant  supplied.  Comparison  of  the  GADS 
solution  with  the  existing  beat  structure  indicated  that  the  CADS  solu¬ 
tion  had  half  the  range  and  variance  of  officer  workload  per  beat.  Solu¬ 
tion  using  GADS  took  longer  than  the  four  hours  for  a  previous,  manual 
solution,  but  much  more  data  was  analyzed,  many  more  alternatives  were 
investigated,  and  eleven  people  instead  of  two  were  involved. 

GADS  was  used  to  explain  the  solution  process  to  other  police  offi¬ 
cers  and  to  city  management.  A  change  in  manpower  availability  necessi¬ 
tated  a  reduction  in  the  number  of  beats  in  the  final  solution  from  43 
to  40.  One  officer,  with  assistance  from  three  others,  spent  42  man-hours 
using  GADS  to  construct  a  new  beat  plan.  The  data  displays  stimulated 
officer  insights  on  zone  accessibility,  neighborhood  characteristics, 
travel  time,  and  personnel  and  equipment  characteristics.  These  insights 
developed  only  during  use  of  CADS,  and  it  is  not  clear  that  they  could  be 
coded  as  computer  data  and  incorporated  into  automated  solution  procedures. 
The  general  question  of  evaluation  of  DSS  in  the  public  sector  is  still 
unresolved.  A  San  Jose  Police  Lieutenant  who  has  worked  with  the  GADS- 
Police  Beat  project  continuously  since  1973,  summarized  the  state  of 
public  sector  DSS  development  when  he  stated,  "We  still  don’t  know  how 
to  write  performance  specifications." 

7.3.2  Individual  and  Group  Training 

A  total  of  fourteen  police  personnel  worked  on  system  design.  There 
were  five  main  users  of  GADS:  two  lieutenants  from  Field  Operations,  one 
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from  Research,  a  staff  assistant  from  Research,  and  a  sergeant  assigned 
to  communications.  Five  other  field  personnel  were  brought  in  when  spe¬ 
cial  knowledge  of  local  conditions  was  needed.  Over  350  hours  of  effort 
were  required  to  create  the  data  base,  and  IBM  personnel  spent  6  months 
developing  programs  for  data  management  and  40  hours  entering  the  special- 
purpose  map  defining  the  beat-building  blocks  (BBB) .  Since  police  per¬ 
sonnel  using  the  GADS  system  had  little  or  no  experience  with  computers, 
a  certain  amount  of  familiarization  and  pre-training  was  necessary.  IBM 
personnel  instructed  the  four  primary  development  teams  on  various  ele¬ 
ments  of  system  operation.  Individual  training  included  familiarizing 
personnel  with  the  mechanics  of  the  system  including  giving  demonstra¬ 
tions  on  how  BBBTs  were  entered  into  the  system,  hox>7  calls  for  service 
were  assigned  X-Y  coordinates,  and  the  procedures  for  moving  through  the 
system.  This  training  took  approximately  four  hours  of  classroom  familiar¬ 
ization  plus  another  six  to  eight  hours  of  actual  data  manipulation  using 
the  scope. 

Since  the  actual  design  of  a  GADS-Police  Beat  system  was  dependent 
on  group  decision  making,  four  teams  participated  in  developing  the 
deployment  plan.  Each  team  consisted  of  two  primary  members;  however, 
additional  personnel  who  had  useful  operating  experience  in  specific 
areas  were  used  in  the  decision  process.  GADS  is  unique  in  that  the 
decision  process  can  be  taken  to  any  organizational  level  and  the  pro¬ 
cess  of  making  a  determination  can  be  quickly  reviewed  any  time  during 
the  process.  By  expending  approximately  15  minutes  of  time  for  orienta¬ 
tion  and  explanation,  a  primary  team  member  was  able  to  involve  opera¬ 
tional  personnel  not  familiar  with  computers  or  GADS  in  the  process. 

On  several  occasions,  team  members  switched  or  worked  alone  without 
adversely  affecting  the  quality  of  decisions  reached.  Although  an  "over¬ 
all"  decision  making  plan  was  outlined,  each  team  ended  by  deciding  on 
its  own  particular  process  and  problem  approach.  Several  teams  abandoned 
their  initial  approach  as  data  began  to  be  manipulated  and  users  became 
more  comfortable  with  GADS.  All  teams  "adjusted"  their  thinking  several 
times  during  the  decision  process  until  an  overall  consensus  was  reached 
between  the  teams.  The  current  operating  system  still  has  the  capability 
of  individual  or  team  usage,  and  training  times  are  about  the  same  as  in 
the  early  experimental  model. 
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8.  CONCLUSIONS 


8 . 1  General 

From  a  limited  survey  of  only  four  types  of  DSS,  it  is  concluded 
that  there  are  a  number  of  similarities  and  differences  in  their  gesta¬ 
tion  environments,  major  events  in  their  developmental  cycles  and  in 
their  operational  characteristics.  There  are  major  differences  in  the 
development  of  public  sector  DSS  vis— a— vis  private  sector  DSS.  Research 
and  development  procurement,  operating  and  maintenance  policies  in  the 
public  sector  are  all  dependent  on  contract  specifications  related  to 
performance  or  accomplishment  of  a  specific  task(s) .  Yearly  budget 
cycles  and  bureaucratic  management  processes  greatly  handicapped  the 
application  of  GADS  technology.  On  the  other  hand  IRIS,  WINS  and  EIS 
were  developed  within  a  corporate  structure  which  could  respond  rapidly 
to  user,  managerial,  and  technological  change.  Since  DSS  are  by  their 
very  nature  evolutionary  and  designed  with  a  capability  for  architec¬ 
tural  adaptability,  the  most  successful  systems  were  found  in  the  private 
sector.  Of  the  four  systems  surveyed,  IRIS  represents  the  best  overall 
example  of  an  operational  DSS  which  has  become  institutionalized  in  an 
organizational  setting,  is  capable  of  adaptation,  is  used  by  both  cor- 
j  porate  staff  and  operational  unit  managers  for  both  strategic  and  tac¬ 

tical  decision  making,  has  an  effective  internal  security  system,  has  a 
good  training  program,  has  an  effective  on-line  operational  cost/ 
effective  evaluation  system,  and  satisfies  the  dual  perceptions  of  the 
senior  corporate  executives  as  well  as  the  operating  field  units.  On 
the  other  hand  WINS  is  more  of  an  example  of  the  ideal  DSS.  It  was 
designed  for  use  by  the  CEO  and  senior  executives,  both  in  the  "board 
room"  group  mode  and  individual  desk  top  mode,  and  is  equipped  with 
elaborate  color  graphics  and  software  decision  models  as  well  as  an 
aggregated  data  base  all  driven  by  a  minicomputer  slaved  to  a  main¬ 
frame.  EIS  has  the  largest  number  of  different  individual  users  and 
different  types  of  decision  problems,  and  provides  the  test  bed  for  the 
open  market  IBM  Trend  Analysis/370  system-  Finally  GADS  provided  an 
experimental  test  vehicle  for  over  15  public  sector  and  one  private 
application,  and  has  made  a  number  of  major  contributions  to  the 
research  literature. 

There  were  a  number  of  similarities  that  all  systems  exhibited: 
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(1)  An  average  of  three  to  Tour  years  were  required  for  develop¬ 
ment  and  implementation. 

(2)  Each  system  had  the  strong  support  of  the  senior  management 
or  Chief  Executive  Officer  when  development  was  initiated. 

(3)  All  systems  had  a  "broker"  who  coalesced  user,  technical  and 
management  interests  for  common  support  of  development  and 
implementation. 

(4)  All  systems  had  a  capability  for  evolution  or  "architectural 
adaptability. " 

8 . 2  Internal  Security 

User  access  and  data  protection  were  major  problems  of  internal 
security  for  multi-level  users  in  widely  distributed  locations.  IRIS 
and  EIS  both  had  elaborate  "access"  and  "need  to  know"  password  pro¬ 
cedures.  They  were  designed  with  the  objectives  of  accommodating  both 
corporate  and  operating  unit  perceptions,  and  were  tailored  to  the 
identity  and  responsibility  of  the  individual  user.  Thus  the  system 
not  only  protects  the  confidentiality  of  personnel  data,  but  preserves 
the  organizational  and  managerial  integrity  of  the  whole  corporation. 

On  the  other  hand  the  WINS  system  required  a  relatively  simple  system 
since  the  whole  system  was  physically  located  in  the  corporate  office 
and  boardroom  area,  and  had  only  a  limited  number  of  senior  executive 
users.  None  of  the  GADS  public  sector  applications  placed  much  empha¬ 
sis  on  internal  security. 

8 *  3  Use  of  Central  Data  Base 

All  of  the  public  sector  DSS  were  appendages  to,  or  integrally 
related  to  central  data  bases.  At  the  one  extreme  the  WINS  minicomputer 
at  corporate  headquarters  was  slaved  to  a  large  regional  computer  center 
mainframe  in  another  state.  At  the  other  extreme  the  IRIS  Project  Group 
controlled  and  managed  the  entire  RCA  personnel  management  data  base 
which  is  used  jointly  for  MIS  transactional  activities  and  for  DSS  type 
ad  hoc  decision  making.  EIS  was  designed  to  operate  both  from  its  own 
data  base,  or  as  an  appendage  from  operational  with  the  First  National 
Bank  System. 
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8 . 4  Training  Programs 

All  of  the  DSS  had  some  form  of  user  training  programs,  which 
included  formal  instruction,  user  manuals  and  a  staff  "coordinator'  or 
"chauffeur."  WINS  was  the  simplest  to  use  and  could  be  done  by  self¬ 
teaching.  GADS  required  4-8  hours  for  a  non-programmer  user  to  become 
proficient,  whereas  EIS  normally  required  two  days  of  instruction. 

IRIS  requires  the  most  extensive  training  program  because  of  a 
wider  range  of  user  skills  at  a  number  of  corporate  and  field  unit 
sites  with  continuous  updating  of  system  capabilities  and  turnover 
of  personnel. 

8.5  Operational  Cost/Benefit  Procedures 

IRIS  was  originally  designed  to  meet  a  cost  per  employee  cri¬ 
terion,  and  has  the  most  extensive  on-line  evaluation  capability.  EIS 
requires  that  each  "profit  center"  user  pay  for  terminal  leasing,  start¬ 
up  cost  and  computer  transactions  through  internal  funds  transfers,  but 
has  no  effective  on-line  evaluation  program.  Neither  WINS  or  GADS 
reported  any  major  effort  at  cost/benefit  analysis  of  system  operations. 
However  a  number  of  researchers  have  attempted  to  evaluate  the  "value" 
or  "utility"  of  some  of  the  GADS  applications. 

9 .  RECOMMENDATIONS 


9 . 1  DSS  Workshop 

AIRMICS  should  take  immediate  action  to  organize  a  DSS  workshop 
with  representation  from  successful  operational  systems,  hardware  and 
software  vendors,  academicians  representing  the  major  disciplines 
involved  in  DSS  research  and  development,  and  potential  Army  users. 

The  workshop  should  include  case  studies,  tutorials,  theoretical  dis¬ 
cussions,  view  of  technology  and  hands-on  demonstration  of  operational 
DSS.  This  workshop  would  be  a  natural  follow-on  to  the  Santa  Clara 
Conference  of  1977,  and  would  do  much  to  synthesize  and  establish  a 
baseline  for  future  research  efforts  and  prototype  Army  field  appli¬ 
cations. 

9 . 2  Evaluation  and  Performance  Specifications 

As  concluded  in  8.1,  a  serious  problem  exists  in  the  design  and 
implementation  of  DSS  in  the  public  sector  because  of  their  intrinsic 
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evolutionary  nature  which  makes  evaluation  and  contract  performance 
specification  virtually  impossible,  and  in  serious  conflict  with  the 
life  cycle-sequential  DOD  procurement  policy.  It  is  recommended  that 
a  research  effort  be  initiated  to  examine  the  current  state  of  DSS 
evaluation  methodologies  and  their  compatibility  with  DOD  procurement 
policies,  and  to  recommend  alternative  solutions. 

9.3  Improvement  of  DSS  Survey  Methodology 

The  survey  reported  here  was  both  limited  in  man-days  of  effort 
and  size  of  sample.  Consequently  much  of  the  field  work  and  litera¬ 
ture  review  were  accomplished  simultaneously.  The  development  of  a 
methodological  set  of  factors  and  attributes  did  not  take  place  until 
work  began  on  the  final  report.  It  is  therefore  recommended  that  after 
a  review  and  critique  of  this  report  is  completed,  that  a  second  itera¬ 
tion  be  initiated  with  a  refined  set  of  factors  and  attributes.  The 
second  iteration  would  be  directed  at  an  investigation  of  a  more  selec¬ 
tive  target  set  of  operational  systems  which  could  provide  a  more  defini¬ 
tive  baseline  to  guide  the  Army  in  applying  DSS  technologies  to  Army 
computer  systems. 
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Appendix  A 


Short  Term  Advisor)'  Services  (STAS) 


STATEMENT  OF  WORK 
TCN:  21  ' I A-g-J 


1 .  General 


Tne  Army  Institute  for  Research  in  Management  Information  and  Computer 
Science  has  a  requirement  for  the  services  of  an  Operations  Research  Scientist 
to  undertake  a  short  term  project  to  produce  a  state-of-the-art  survey  and 
analysis  of  the  application  of  Decision  Support  System  (DSS)  technologies  to 
business  type  automatic  data  processing  systems.  This  study  is  beyond  the 
present  capabilities  of  AIRMICS  personnel. 

2.  Objectives 


'  -  The  work  to  be  accomplished  between  15  Sep  1978  and  15  January  1979 
is  to  produce  an  analysis  of  existent  DSS  and  their  supporting  hardware  and 
software  technology  base,  and  to  recommend  further  research  into  potential 
application  of  this  technology  to  computer  systems. 

3.  Specific  Tasks 

a.  Gather  and  analyze  published  work  on  DSS  developed  for  use  in  the 
civilian  community. 

b.  Review  and  analyze  reasons  for  success  or  failure  of  DSS  developed 
J  for  civilian  use.  As  a  minimum  the  following  known  installations  will  be 

queried:  RCA;  Gould,  Inc.  ;  First  National  Bank  of  Chicago;  IBM.- 

4 .  Reporting  Requirements 

A  report  will  be  submitted  by  January  15,  1979  which  reflects  the  activity, 
purpose,  procedures,  documentation  and  summary  of  work  performed  under  each 
task  in  paragraph  3.  In  addition  this  report  will  include  a  list  of  recommen¬ 
dations  for  future  research.  ^ 

'  -5.  '  Special  Qualifications  ’  — •  _ 

The  Operations  Research  Scientist  selected  for  these  services  must  he  at 
'the  Ph.D.  level  with  a  background  in  computer  applications,  in  systems 
engineering,  and  man -machine  design  methodologies. 

6.  ‘  Place  .  and  Period  of  Performance  • 

- _  20  rB- 

a.  Twenty  working  days  during  the  period  15— S-ejr — “ISFTS  and  15  Jan  1979. 
which  includes  50%  of  work  at  AIRMICS,  or  ten  days.  Travel  will  be  as  follows: 

Q)  One  trip  to  Ft.  l.ee,  VA  of  1-2  days  duration:0One  trip  to  Gould  Corp.  Cliica 
(2)  One  trip  to  IBM,  San  Jose,  CA,  1-2  days  Illinois  of  1-2  days  durati 

7.  Restrict ions^Ono  trip  to  RCA,  Summerville,  N'.J.  1-2  days  duration. 

There  is  no  known  potential  conflict  of  interest  associated  with  this 
task. 
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